【DDD】领域驱动设计精要

本文算是《领域驱动设计》这本书的读书笔记,加上自己的一些读后感。网上有很多这本书的读书笔记,但是都是别人的,不如自己总结的理解深刻。建议大家在读这本书时结

 

本文算是《领域驱动设计》这本书的读书笔记,加上自己的一些读后感。网上有很多这本书的读书笔记,但是都是别人的,不如自己总结的理解深刻。建议大家在读这本书时结合《实现领域驱动设计》一起看,同时,一定要去实际建模和编码,理论联系实际才能得其精髓。

本文是【DDD】系列文章的第一篇,可参考:使用领域驱动设计思想实现业务系统

定义

DDD是Domain driven design(领域驱动设计)的简称,是一种软件设计和开发的方法论,特别适用于复杂业务领域软件设计和开发。可参考wiki: Domain-driven_design

核心

  1. 将所有业务逻辑内聚到业务领域(domain)层,将设计和开发的关注点聚焦到业务领域;
  2. 建立通用的‘业务领域语言(Ubiquitous Language)’,Ubiquitous Language是工程师和业务领域专家(可以是产品经理、运营、业务相关人员)的桥梁;
  3. 战略上,通‘上下文(Bounded Context)’解耦各个业务系统/组件,通过‘防腐层(Anticorruption layer)’确保自有业务领域不受外界污染,通过‘开放主机服务(Open Host Service)’向外界公开服务;
  4. 战术上,将业务对象建模为entity和value object,entity有唯一业务标识且在其生命周期中状态可变,value object与之相反;关联性强的entity和value object聚合成一个Aggregate,每个Aggregate有一个root entity,确保Aggregate内容业务规则和行为的一致性;业务行为尽量建模在entity/ value object 上,当业务行为无法建模到任何业务entity/value object时,可以使用领域服务(domain service),使用factory创建复杂的业务entity,使用repository实现实体的重建和持久化操作;领域相关的通知等可以通过domain event发布出去。

概念

  • Bounded context:边界上下文

划分领域边界,边界内领域模型保持一致,强调内聚,并与边界外的领域模型解耦。

  • Entity:领域实体

有唯一标识,可变的业务实体对象,它有着自己的生命周期。比如User、帖子等。

  • Value Object:领域值对象

没有唯一业务标识,通常依附于其他领域实体,值对象的内容不可变,要么被整体替换。如:用户点赞行为等。

  • Aggregate:聚合

是一组业务关联度很强的实体/值对象集合,每个聚合都有一个根实体(Root Entity),通过根实体可以路由到整个聚合。

  • Domain Event:领域事件

领域中发生的异步处理事件、异步消息通知等,比如:异步写入的登录历史记录。通常借助消息队列实现。

  • Domain Service:领域服务

当某些业务行为无法归类到某一个Entity/Value Object时,我们便可以创建领域服务来完成。比如:账户转账场景,涉及到两个不同的Account实体,再比如社区的敏感词过滤场景,帖子可以用,评论亦可以用,因此可以抽离到ContentFilter中完成。

  • Repository:仓库

严格意义上将仓库是基础设施层的东西,但是为了保持领域模型的整体性,我们将仓库的接口定义放到领域中,这样可以在领域中约束实体/值对象的增删改查接口,同时还可以方便地完成仓库的内存形式实现,使得领域模型弱依赖于持久化层。这一点在书中被成为‘依赖倒置’(参考《实现领域驱动设计》P372)。

  • Factory:领域对象工厂

用于复杂领域对象的创建/重建。重建是指通过respostory加载持久化对象后,重建领域对象。

图解

分层图

User Interface —— 用户界面层。提供与用户/调用者交互的接口,可以是View,也可以是Restful api,还可以是二进制形式的tcp协议接口等。

Application —— 应用服务层。组合domain和infrastructure,完成具体的业务逻辑。

Domain —— 业务领域层。是ddd中的核心层,内聚所有的业务逻辑,保持领域的一致性。通常他可能会用到infrastructure层的公共组件。

Infrastructure —— 基础设施层。提供公共服务组件,比如validation、登录态校验、trace日志记录等等。

 

模式图

这张图囊括了DDD中的所有核心概念,上面部分是战术相关,下面部分是战略相关。不再赘述,建议读者直接查阅DDD原书,有详细介绍。值得反复细读。

思考

  • DDD vs MVC 异同之处?
  • DDD vs CRUD 的区别是什么? 可参考:http://jlhood.com/there-is-no-u-in-crud/
  • DDD 能带来什么好处?有什么不好的地方?
  • DDD 适用的场景?
  • 你为什么选择使用DDD?

在评论区,附上自己的思考,会不间断更新。欢迎大家写上你们的理解。