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

本文是【DDD & 重构】系列文章的第一篇，可参考：通过业务系统的重构实践DDD

定义

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

核心

将所有业务逻辑内聚到业务领域（domain）层，将设计和开发的关注点聚焦到业务领域；
建立通用的‘业务领域语言（Ubiquitous Language）’，Ubiquitous Language是工程师和业务领域专家（可以是产品经理、运营、业务相关人员）的桥梁；
战略上，通‘上下文（Bounded Context）’解耦各个业务系统/组件，通过‘防腐层（Anticorruption layer）’确保只有业务领域不受外界污染，通过‘开放主机服务（Open Host Service）’向外界公开服务；
战术上，将业务对象建模为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发布出去。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

原文链接：https://www.f2er.com/javaschema/282727.html