领域驱动设计实践

文章内容全部来自张逸《领域驱动设计实践（战略+战术）》

领域驱动是什么

领域驱动设计就是针对软件开发领域提出的一套系统与理论分析方法，是“一种思维方式，也是一组优先任务，它旨在加速那些必须处理复杂领域的软件项目的开发”。领域驱动设计贯穿了整个软件开发的生命周期，包括对需求的分析、建模、架构、设计，甚至最终的编码实现，乃至对编码的测试与重构。
领域驱动设计强调领域模型的重要性，并通过模型驱动设计来保障领域模型与程序设计的一致。从业务需求中提炼出统一语言（Ubiquitous Language），再基于统一语言建立领域模型；这个领域模型会指导着程序设计以及编码实现；最后，又通过重构来发现隐式概念，并运用设计模式改进设计与开发质量。

战略设计阶段

问题域方面

针对问题域，引入限界上下文（Bounded Context）和上下文映射（Context Map）对问题域进行合理的分解，识别出核心领域（Core Domain）与子领域（SubDomain），并确定领域的边界以及它们之间的关系，维持模型的完整性。

架构方面

通过分层架构来隔离关注点，尤其是将领域实现独立出来，能够更利于领域模型的单一性与稳定性；引入六边形架构可以清晰地表达领域与技术基础设施的边界；CQRS 模式则分离了查询场景和命令场景，针对不同场景选择使用同步或异步操作，来提高架构的低延迟性与高并发能力。

战术设计阶段

整个软件系统被分解为多个限界上下文（或领域）后，就可以分而治之，对每个限界上下文进行战术设计。

演进的领域驱动设计过程

战略设计会控制和分解战术设计的边界与粒度，战术设计则以实证角度验证领域模型的有效性、完整性与一致性，进而以演进的方式对之前的战略设计阶段进行迭代，从而形成一种螺旋式上升的迭代设计过程。

认识分层架构

经典分层架构

层次	职责
用户界面/展现层	负责向用户展现信息以及解释用户命令
应用层	很薄的一层，用来协调应用的活动，它不包含业务逻辑，它不保留业务对象的状态，但它保有应用任务的进度状态
领域层	本层包含关于领域的信息，这是业务软件的核心所在。在这里保留业务对象的状态，对业务对象和它们状态的持久化被委托给了基础设施层
基础设施层	本层作为其他层的支撑库存在。它提供了层间的通信，实现对业务对象的持久化，包含对用户界面层的支撑库等作用

分层的依据与原则

分层的第一个依据是基于关注点为不同的调用目的划分层次。
分层的第二个依据是面对变化。
层与层之间的关系应该是正交的。
保证同一层的组件处于同一个抽象层次。

分层架构的演化

分层架构是一种架构模式，但终归它的目的是为了改进软件的架构质量，我们在运用分层架构时，必须要遵守架构设计的最高原则，即建立一个高内聚、松耦合的软件系统架构。

整洁架构

在架构设计时，我们应设计出干净的应用层和领域层，保持它们对业务逻辑的专注，而不掺杂任何具体的技术实现，从而完成领域与技术之间的完全隔离，这一思想被 Robert Martin 称之为整洁架构（Clean Architecture）。

领域模型就是业务逻辑的模型，它应该是完全纯粹的。
对下，例如，针对数据库、消息队列或硬件设备，可以认为是一个南向网关，对于当前限界上下文是一种输出的依赖；
对上，例如，针对 Web 和 UI，可以认为是一个北向网关，对于当前限界上下文是一种输入的依赖。