Шаблон DDD от знаний к практике

задний план

Введение в ДДД

История ДДД.

Связь между DDD и микросервисами

1. функциональное измерение
2. Показатели качества (включая производительность и доступность)
3. Инженерное измерение

Архитектура системы определяется архитектурными границами в системе, а также зависимостями между границами, независимо от того, как вызываются компоненты в системе. Сама так называемая услуга - это просто форма разделения поведения приложения с немного более высокой стоимостью, чем метод вызова функций, и не имеет ничего общего с архитектурой системы.

1. C Независимое развертывание ресурсов: ресурсы более разумны, а мощность можно расширять и заключать контракты независимо друг от друга.
2. Эластичный сервис: повторная попытка, автоматический выключатель, переход на более раннюю версию и т. д. обеспечили изоляцию сбоя.
3. Независимость от стека технологий: C может быть написан на других языках и больше подходит для персонализированных стеков командных технологий.
4. Команда независима: могут нести ответственность разные команды.

• Во-первых, агрегируйте корни, чтобы обеспечить правильность внутренних правил сущностей и непротиворечивость данных;
• Во-вторых, внешние объекты могут ссылаться на корень агрегата только по идентификатору и не могут ссылаться на объекты внутри корня агрегата;
• В-третьих, транзакция базы данных не может быть разделена между корнями агрегатов, и согласованность данных между ними должна быть гарантирована согласованностью в конечном итоге.

Связанные термины и основные понятия DDD

поле

Поддомены

основной домен

общий домен

домен поддержки

единый язык

ограниченный контекст

полимеризация

1. Какая информация должна находиться в границах агрегата, без чего его нельзя назвать действительным агрегатом;
2. Состояние некоторых объектов в агрегате должно удовлетворять определенному бизнес-правилу:

• Агрегат имеет только один агрегатный корень, и этот агрегатный корень может существовать независимо.Другие сущности или объекты-значения в агрегате зависят от агрегатного корня.
• Доступ извне возможен только к корню агрегата, а корень агрегата поддерживает внутреннюю согласованность агрегата.

Совокупный корень

организация

объект значения

1. модель кровопотери
2. Модель анемии
3. модель гиперемии
4. Модель отека крови

задний план

public class Article implements Serializable {
    private Integer id;
    private String title;
    private Integer classId;
    private Integer authorId;
    private String authorName;
    private String content;
    private Date pubDate;
    //getter/setter/toString
}

public interface ArticleDao extends BaseDao<Article>{
    //...
}

Repository("articleDao")
public class ArticleDaoImpl implements ArticleDao{
    //...
}

public interface ArticleService extends BaseService<Article>{
    //...
}

@Service(value="articleService")
public class ArticleServiceImpl implements ArticleService {
    //...
}

Примеры четырех режимов

модель кровопотери

public class Article implements Serializable {
    private Integer id;
    private String title;
    private Integer classId;
    private Integer authorId;
    private String authorName;
    private String content;
    private Date pubDate;
    //getter/setter/toString
}

public interface ArticleDao {
     public Article getArticleById(Integer id);
     public Article findAll();
     public void updateArticle(Article article);
}

Модель анемии

public class Article implements Serializable {
    private Integer id;
    private String title;
    private Integer classId;
    private Integer authorId;
    private String authorName;
    private String content;
    private Date pubDate;
    //getter/setter/toString
    //判断是否是热门分类(假设等于57或102的类别的文章就是热门分类的文章)
    public boolean isHotClass(Article article){
        return Stream.of(57,102)
            .anyMatch(classId -> classId.equals(article.getClassId()));
    }
    //更新分类，但未持久化，这里不能依赖Dao去操作实体化
    public Article changeClass(Article article, ArticleClass ac){
        return article.setClassId(ac.getId());
    }
}

@Repository("articleDao")
public class ArticleDaoImpl implements ArticleDao{
    @Resource
    private ArticleDao articleDao;
    public void changeClass(Article article, ArticleClass ac){
        article.changeClass(article, ac);
        articleDao.update(article)
    }
}

• Постоянная логика домена, тесно зависящая от объекта домена, разделена на уровень службы, что недостаточно для объектно-ориентированного подхода.
• Сервисный уровень слишком тяжелый

модель гиперемии

Сервис (инкапсуляция транзакции) —> Объект домена DAO

public class Article implements Serializable {
    @Resource
    private static ArticleDao articleDao;
    private Integer id;
    private String title;
    private Integer classId;
    private Integer authorId;
    private String authorName;
    private String content;
    private Date pubDate;
    //getter/setter/toString
    //使用articleDao进行持久化交互
    public List<Article> findAll(){
        return articleDao.findAll();
    }
    //判断是否是热门分类(假设等于57或102的类别的文章就是热门分类的文章)
    public boolean isHotClass(Article article){
        return Stream.of(57,102)
            .anyMatch(classId -> classId.equals(article.getClassId()));
    }
    //更新分类，但未持久化，这里不能依赖Dao去操作实体化
    public Article changeClass(Article article, ArticleClass ac){
        return article.setClassId(ac.getId());
    }
}

• Более соответствует принципам ООП;
• Уровень службы очень тонкий и действует только как фасад и не имеет отношения к DAO.

• DAO и объект домена образуют двунаправленную зависимость, а сложные двунаправленные зависимости могут привести ко многим потенциальным проблемам.
• Как разделить логику сервисного уровня и логику доменного уровня очень неоднозначно, в реальных проектах из-за различий в уровне дизайна и разработчиков вся структура может быть хаотичной и беспорядочной.

Модель отека крови

Объект домена (инкапсуляция транзакций, бизнес-логика) DAO

• Упрощенное наслоение
• Также в соответствии с ОО

• Многие логики службы, которые не являются логикой домена, также принудительно помещаются в объект домена, вызывая нестабильность модели объекта домена;
• Объект домена предоставляет веб-слою слишком много информации, что может вызвать неожиданные побочные эффекты.

Модернизация существующих устаревших системных практик с помощью DDD

Идеальное сочетание DDD и семейства Spring

Модуль

import com.company.team.bussiness.counter.*;//计数上下文
import com.company.team.bussiness.category.*;//分类上下文
import com.company.team.bussiness.comment.*;//评论上下文

import com.company.team.bussiness.cms.domain.valobj.*;//领域对象-值对象
import com.company.team.bussiness.cms.domain.entity.*;//领域对象-实体
import com.company.team.bussiness.cms.domain.aggregate.*;//领域对象-聚合根
import com.company.team.bussiness.cms.service.*;//领域服务
import com.company.team.bussiness.cms.repo.*;//领域资源库
import com.company.team.bussiness.cms.facade.*;//领域防腐层

доменный объект

package com.company.team.bussiness.domain.aggregate;
import ...;

public class Article {

    @Resource
    private CategoryRepository categoryRepository;

    private int articleId; //文章id
    ...
    private ArticleCount articleCount; //文章计数器
    //getter & setter

    //查询计数显示数量，这里简化一些逻辑，甚至是不符合实际业务场景，这不重要，这里只为直观表达意思
    public Integer getShowArticleCount() {
            if(this.articleCount == null){
            return 0;
        }
        return this.articleCount.realCount + categoryRepository.getCategoryWeight(this.category) + (this.articleCount.adCount * DayUtils.calDaysByNow(this.articleCount.deadDays));
    }
}

Библиотека ресурсов

import com.company.team.bussiness.repo.dao.ArticleDao;//数据库访问对象-文章
import com.company.team.bussiness.repo.dao.CommentDao;//数据库访问对象-评论
import com.company.team.bussiness.repo.dao.po.ArticlePO;//数据库持久化对象-文章
import com.company.team.bussiness.repo.dao.po.CommentPO;//数据库持久化对象-评论
import com.company.team.bussiness.repo.cache.ArticleObj;//分布式缓存访问对象-文章缓存访问

package com.company.team.bussiness.repo;
import ...;

@Repository
public class ArticleRepository {
    @Autowired
    private ArticleDao articleDao;
    @AutoWired
    private articleDaoCacheAccessObj articleCacheAccessObj;

    public Article getArticleById(int articleId) {
        Article article = articleCacheAccessObj.get(articleId);
        if(article!=null){
            return article;
        }
        article = getArticleFromDB(articleId);
        articleCacheAccessObj.add(articleId, article);
        return article;
    }

    private Article getArticleFromDB(int articleId) {...}
}

антикоррозийный слой

• Необходимо перевести модель во внешнем контексте в модель, которая понимает контекст.
• Для отношений командного сотрудничества между различными контекстами, если это отношения преданных, рекомендуется ввести антикоррозийный слой, чтобы избежать эрозии этого контекста внешними изменениями контекста.
• Этот доступ широко используется в этом контексте, чтобы избежать изменений, затрагивающих слишком большую область.

package com.company.team.bussiness.facade;
import ...;

@Component
public class ArticleFacade {

    @Resource
    private ArticleService articleService;

    public Article getArticle(ArticleContext context) {
        ArticleResponse resp = articleService.getArticle(context.getArticleId());
        return buildArticle(resp);
    }

    private Article buildArticle(ArticleResponse resp) {...}
}

Доменные службы

package com.company.team.bussiness.service.impl
import ...;
@Service
public class CommentServiceImpl implements CommentService {
       @Resource
    private CommentFacade commentFacade;
       @Resource
    private ArticleRepository articleRepo;
    @Resource
    private ArticleService articleService;

    @Override
    public CommentResponse commentArticle(CommentContext commentContext) {
        Article article = articleRepo.getArticleById(commentContext.getArticleId());//获取文章聚合根
        commentFacade.doComment(commentContext);//增加计数信息
        return buildCommentResponse(commentContext,article);//组装评论后的文章信息
    }

    private CommentResponse buildCommentResponse(CommentContext commentContext, Article article) {...}
}

Структура демонстрационного пакета