DDD 模式从天书到实践

背景

DDD 介绍

DDD 的发展史

DDD 与微服务的关系

1. 功能维度
2. 质量维度（包括性能和可用性）
3. 工程维度

系统架构是由系统内部的架构边界，以及边界之间的依赖关系所定义的，与系统中组件之间的调用方式无关。 所谓的服务本身只是一种比函数调用方式成本稍高的，分割应用程序行为的一种形式，与系统架构无关。

1. C 独立部署资源：资源更合理的倾斜，独立扩容缩容。
2. 弹力服务：重试、熔断、降级等，已达到故障隔离。
3. 技术栈独立：C 可以使用其他语言编写，更合适个性化团队技术栈。
4. 团队独立：可以由不同团队负责。

• 第一，聚合根来保证内部实体规则的正确性和数据一致性；
• 第二，外部对象只能通过 id 来引用聚合根，不能引用聚合根内部的实体；
• 第三，聚合根之间不能共享一个数据库事务，他们之间的数据一致性需要通过最终一致性来保证。

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)
    }
}

• Domain Object 的部分比较紧密依赖的持久化 Domain Logic 被分离到 Service 层，显得不够 OO
• Service 层过于厚重

充血模型

Service (事务封装) —> Domain Object <—> 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());
    }
}

• 更加符合 OO 的原则；
• Service 层很薄，只充当 Facade 的角色，不和 DAO 打交道。

• DAO 和 Domain Object 形成了双向依赖，复杂的双向依赖会导致很多潜在的问题。
• 如何划分 Service 层逻辑和 Domain 层逻辑是非常含混的，在实际项目中，由于设计和开发人员的水平差异，可能 导致整个结构的混乱无序。

胀血模型

Domain Object (事务封装，业务逻辑) <—> DAO

• 简化了分层
• 也算符合 OO

• 很多不是 Domain Logic 的 Service 逻辑也被强行放入 Domain Object ，引起了 Domain Object 模型的不稳定；
• Domain Object 暴露给 Web 层过多的信息，可能引起意想不到的副作用。

运用 DDD 改造现有旧系统实践

DDD 与 Spring 家族的完美结合

模块（Module）

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) {...}
}

示范包结构