DDD
Contents
DDD
领域驱动设计 (Domain-Driven Design，简称DDD）
领域驱动设计 (DDD) 是由 Eric Evans 发明的一个概念。他在 2004 年出版的《领域驱动设计》一书 (即”大蓝皮书“) 中探讨了这个概念 领域驱动设计(Domain Driven Design,DDD)
Martin Fowler在《企业应用架构模式》一书中写道:
I found this(business logic) a curious term because there are few things that are less logical than business logic.
初略翻译过来可以理解为: 业务逻辑是很没有逻辑的逻辑。
很多时候软件的业务逻辑是无法通过推理而得到的，有时甚至是被臆想出来的。这样的结果使得原本已经很复杂的业务变得更加复杂而难以理解。而在具体编码实现时，除了应付业务上的复杂性，技术上的复杂性也不能忽略，比如我们要讲究技术上的分层，要遵循软件开发的基本原则，又比如要考虑到性能和安全等等。
DDD分为战略设计和战术设计。在战略设计中，我们讲求的是子域和限界上下文(Bounded Context,BC)的划分，以及各个限界上下文之间的上下游关系。当前如此火热的"在微服务中使用DDD"这个命题，究其最初的逻辑无外乎是"DDD中的限界上下文可以用于指导微服务中的服务划分”。事实上，限界上下文依然是软件模块化的一种体现，与我们一直以来追求的模块化原则的驱动力是相同的，即通过一定的手段使软件系统在人的大脑中更加有条理地呈现，让作为"目的"的人能够更简单地了解进而掌控软件系统。
如果说战略设计更偏向于软件架构，那么战术设计便更偏向于编码实现。DDD 战术设计的目的是使得业务能够从技术中分离并突显出来，让代码直接表达业务的本身，其中包含了聚合根、应用服务、资源库、工厂等概念。虽然 DDD 不一定通过面向对象(OO)来实现，但是通常情况下在实践 DDD 时我们采用的是 O O编程范式，行业中甚至有种说法是"DDD是OO进阶”，意思是面向对象中的基本原则(比如SOLID)在DDD中依然成立。
实现业务的3种常见方式
- 基于"Service + 贫血模型"的实现
- 基于事务脚本的实现
- 基于业务的分包
聚合根 (Aggreate Root, AR)就是软件模型中那些最重要的以名词形式存在的领域对象，比如本文示例项目中的Order和Product。又比如，对于一个会员管理系统，会员(Member)便是一个聚合根；对于报销系统，报销单(Expense)便是一个聚合根；对于保险系统，保单(Policy)便是一个聚合根。聚合根是主要的业务逻辑载体，DDD中所有的战术实现都围绕着聚合根展开。
在本例中，Order中的品项(orderItems)和总价(totalPrice)是密切相关的，orderItems的变化会直接导致totalPrice的变化，因此，这二者自然应该内聚在Order下。此外，totalPrice的变化是orderItems变化的必然结果，这种因果关系是业务驱动出来的，为了保证这种"必然”，我们需要在Order.changeProductCount()方法中同时实现"因"和"果”，也即聚合根应该保证业务上的一致性。在DDD中，业务上的一致性被称为不变条件(Invariants)。
对聚合根的设计需要提防上帝对象(God Object)，也即用一个大而全的领域对象来实现所有的业务功能。上帝对象的背后存在着一种表面上看似合理的逻辑: 既然要内聚，那么让我们把所有相关的东西都聚到一起吧，比如用一个Product类来应付所有的业务场景，包括订单、物流、发票等等。这种机械的方式看似内聚，实则恰恰是内聚性的反面。要解决这样的问题依然需要求助于限界上下文，不同限界上下文使用各自的通用语言(Ubiquitous Language)，通用语言要求一个业务概念不应该有二义性，在这样的原则下，不同的限界上下文可能都有自己的Product类，虽然名字相同，却体现着不同的业务。
聚合根的实现应该与框架无关: 既然DDD讲求业务复杂度和技术复杂度的分离，那么作为业务主要载体的聚合根应该尽量少地引用技术框架级别的设施，最好是POJO。试想一下，如果你的项目哪天需要从Spring迁移到Play，而你可以自信地给老板说，直接将核心Java代码拷贝过去即可，这将是一种多么美妙的体验。又或者说，很多时候技术框架会有"大步"的升级，这种升级会导致框架中API的变化并且不再支持向后兼容，此时如果我们的领域模与框架无关，那么便可做到在框架升级的过程中幸免于难。
聚合根之间的引用通过ID完成: 在聚合根边界设计合理的情况下，一次业务用例只会更新一个聚合根，此时你在该聚合根中去引用另外聚合根的整体有什么好处呢？在本文示例中，一个Order下的OrderItem引用了ProductId，而不是整个Product。 聚合根内部的所有变更都必须通过聚合根完成: 为了保证聚合根的一致性，同时避免聚合根内部逻辑向外泄露，客户方只能将整个聚合根作为统一调用入口。 如果一个事务需要更新多个聚合根，首先思考一下自己的聚合根边界处理是否出了问题，因为在设计合理的情况下通常不会出现一个事务更新多个聚合根的场景。如果这种情况的确是业务所需，那么考虑引入消息机制和事件驱动架构，保证一个事务只更新一个聚合根，然后通过消息机制异步更新其他聚合根。
聚合根不应该引用基础设施。 外界不应该持有聚合根内部的数据结构。 尽量使用小聚合。
实体 vs 值对象 软件模型中存在实体对象(Entity)和值对象(Value Object)之说，这种划分方式事实上并不是DDD的专属，但是在DDD中我们非常强调这两者之间的区别。
实体对象表示的是具有一定生命周期并且拥有全局唯一标识(ID)的对象，比如本文中的Order和Product，而值对象表示用于起描述性作用的，没有唯一标识的对象，比如Address对象。
聚合根一定是实体对象，但是并不是所有实体对象都是聚合根，同时聚合根还可以拥有其他子实体对象。聚合根的ID在整个软件系统中全局唯一，而其下的子实体对象的ID只需在单个聚合根下唯一即可。 在本文示例项目中，OrderItem是聚合根Order下的子实体对象:
public class OrderItem { private ProductId productId; private int count; private BigDecimal itemPrice; } 可以看到，虽然OrderItem使用了ProductID作为ID，但是此时我们并没有享受ProductID的全局唯一性，事实上多个Order可以包含相同ProductID的OrderItem，也即多个订单可以包含相同的产品。
区分实体和值对象的一个很重要的原则便是根据相等性来判断，实体对象的相等性是通过ID来完成的，对于两个实体，如果他们的所有属性均相同，但是ID不同，那么他们依然两个不同的实体，就像一对长得一模一样的双胞胎，他们依然是两个不同的自然人。对于值对象来说，相等性的判断是通过属性字段来完成的。比如，订单下的送货地址Address对象便是一个典型的值对象:
值对象的不变性使得程序的逻辑变得更加简单，你不用去维护复杂的状态信息，需要的时候创建，不要的时候直接扔掉即可，使得值对象就像程序中的过客一样。在DDD建模中，一种受推崇的做法便是将业务概念尽量建模为值对象。
另外，需要指明的是，实体和值对象的划分并不是一成不变的，而应该根据所处的限界上下文来界定，相同一个业务名词，在一个限界上下文中可能是实体，在另外的限界上下文中可能是值对象。比如，订单Order在采购上下文中应该建模为一个实体，但是在物流上下文中便可建模为一个值对象。
上下文: 单词或语句在其中出现的、可以决定其意思的环境。模型的语句只能在上下文中进行理解。 有界上下文: 对边界 (通常是一个子系统或特定团队的工作) 的描述，特定模型在其中定义，同时也是模型的适用范围。
https://www.infoq.cn/article/tbHvBulrMyBA3kA5378q?utm_source=rss&utm_medium=article https://insights.thoughtworks.cn/backend-development-ddd/
DAO, Data Access Object
演进式设计
有一种解决方案，按照演进式设计的理论，让系统的设计随着系统实现的增长而增长。我们不需要作提前设计，就让系统伴随业务成长而演进。这当然是可行的，敏捷实践中的重构、测试驱动设计及持续集成可以对付各种混乱问题。重构——保持行为不变的代码改善清除了不协调的局部设计，测试驱动设计确保对系统的更改不会导致系统丢失或破坏现有功能，持续集成则为团队提供了同一代码库。
贫血领域对象
贫血领域对象 (Anemic Domain Object）是指仅用作数据载体，而没有行为和动作的领域对象。
在我们习惯了J2EE的开发模式后，Action/Service/DAO这种分层模式，会很自然地写出过程式代码，而学到的很多关于OO理论的也毫无用武之地。使用这种开发方式，对象只是数据的载体，没有行为。以数据为中心，以数据库ER设计作驱动。分层架构在这种开发模式下，可以理解为是对数据移动、处理和实现的过程。
软件系统复杂性应对 解决复杂和大规模软件的武器可以被粗略地归为三类：抽象、分治和知识。
分治 把问题空间分割为规模更小且易于处理的若干子问题。分割后的问题需要足够小，以便一个人单枪匹马就能够解决他们；其次，必须考虑如何将分割后的各个部分装配为整体。分割得越合理越易于理解，在装配成整体时，所需跟踪的细节也就越少。即更容易设计各部分的协作方式。评判什么是分治得好，即高内聚低耦合。
抽象 使用抽象能够精简问题空间，而且问题越小越容易理解。举个例子，从北京到上海出差，可以先理解为使用交通工具前往，但不需要一开始就想清楚到底是高铁还是飞机，以及乘坐他们需要注意什么。
知识 顾名思义，DDD可以认为是知识的一种。
DDD提供了这样的知识手段，让我们知道如何抽象出限界上下文以及如何去分治。
我们将架构设计活动精简为以下三个层面：
业务架构——根据业务需求设计业务模块及其关系 系统架构——设计系统和子系统的模块 技术架构——决定采用的技术及框架 以上三种活动在实际开发中是有先后顺序的，但不一定孰先孰后。在我们解决常规套路问题时，我们会很自然地往熟悉的分层架构套 (先确定系统架构），或者用PHP开发很快 (先确定技术架构），在业务不复杂时，这样是合理的。
跳过业务架构设计出来的架构关注点不在业务响应上，可能就是个大泥球，在面临需求迭代或响应市场变化时就很痛苦。
DDD的核心诉求就是将业务架构映射到系统架构上，在响应业务变化调整业务架构时，也随之变化系统架构。而微服务追求业务层面的复用，设计出来的系统架构和业务一致；在技术架构上则系统模块之间充分解耦，可以自由地选择合适的技术架构，去中心化地治理技术和数据。
战略建模 战略和战术设计是站在DDD的角度进行划分。战略设计侧重于高层次、宏观上去划分和集成限界上下文，而战术设计则关注更具体使用建模工具来细化上下文。
领域 现实世界中，领域包含了问题域和解系统。一般认为软件是对现实世界的部分模拟。在DDD中，解系统可以映射为一个个限界上下文，限界上下文就是软件对于问题域的一个特定的、有限的解决方案。
限界上下文 限界上下文
一个由显示边界限定的特定职责。领域模型便存在于这个边界之内。在边界内，每一个模型概念，包括它的属性和操作，都具有特殊的含义。
一个给定的业务领域会包含多个限界上下文，想与一个限界上下文沟通，则需要通过显示边界进行通信。系统通过确定的限界上下文来进行解耦，而每一个上下文内部紧密组织，职责明确，具有较高的内聚性。
一个很形象的隐喻：细胞质所以能够存在，是因为细胞膜限定了什么在细胞内，什么在细胞外，并且确定了什么物质可以通过细胞膜。
限界上下文之间的映射关系
合作关系 (Partnership）：两个上下文紧密合作的关系，一荣俱荣，一损俱损。 共享内核 (Shared Kernel）：两个上下文依赖部分共享的模型。 客户方-供应方开发 (Customer-Supplier Development）：上下文之间有组织的上下游依赖。 遵奉者 (Conformist）：下游上下文只能盲目依赖上游上下文。 防腐层 (Anticorruption Layer）：一个上下文通过一些适配和转换与另一个上下文交互。 开放主机服务 (Open Host Service）：定义一种协议来让其他上下文来对本上下文进行访问。 发布语言 (Published Language）：通常与OHS一起使用，用于定义开放主机的协议。 大泥球 (Big Ball of Mud）：混杂在一起的上下文关系，边界不清晰。 另谋他路 (SeparateWay）：两个完全没有任何联系的上下文。
https://developer.aliyun.com/article/2255?spm=a2c6h.12873639.0.0.4f0121d9i6g8vv
https://domain-driven-design.org/zh/ddd-concept-reference.html
Author -
LastMod 2021-03-02