领域驱动设计:软件核心复杂性应对之道，领域驱动设计笔记

因为实践DDD 的关键不是这个战术层面模型的实现，而是遵守其宏观的领域驱动设计思想，比如统一语言、领域模型与代码的一致性、子领域与上下文的拆分与映射、领域的分离等。在划分领域时，我们也离不开时间尺度对象，通过收敛相关的时间尺度对象来划分领域。 Eric Evans提供的模型驱动设计的结构要素以及它们之间的关系如下图所示： 上线活动：当运营方确认该活动可以上线后，就可以对该活动进行上线操作。

如果团队没有熟悉应用程序所需领域知识的领域专家，那么即使是最熟练的开发人员也无济于事。领域驱动的设计实践依靠持续迭代和持续集成来构建高度可扩展的项目，但这种基于时间的迭代和持续集成可能会成为某些团队的障碍，特别是如果过去的经验是基于僵化的开发模型，例如瀑布模型。

1、领域驱动设计实战

不要太关注书中描述的具体技术和设计方法。领域模型贯穿概念模型、逻辑和物理设计模型，贯穿从需求收集、分析、设计、实现到测试部署的整个开发过程。要注意从整体的角度去理解。领域驱动思维收集需求时，与业务专家的沟通就开始了领域模型的建模工作；深入分析和整合需求。领域驱动设计是要深入了解大象并了解其特征、行为和需求。

2、领域驱动设计误区分析论文

一个域可以划分为多个子域，一个子域又可以划分为多个子子域。有界上下文本质上是一种子子域。那么在分解业务时，业务模块是域、子域还是子子域呢？领域是知识或活动的集合。与软件系统相比，领域是软件应用程序要解决的实际问题的领域。但主要区别在于，领域模型设计的出发点是客观世界，因此保证了客观需求与直接需求的一致性。在此基础上指导程序开发，保证软件与需求的一致性。

3、领域驱动设计教程

DDD强调需要领域专家才能构建项目所依赖的统一语言和领域模型。然而，如果项目的技术复杂度很高，那么领域理解它就是一个挑战。领域服务：领域服务就好比一个专业的服务提供者，可以处理领域内复杂的业务逻辑或者跨多个实体的操作，类似于医生或律师。

4、领域驱动设计与微服务

本书提供了领域驱动设计的系统方法，集成了一些普遍接受的最佳实践，融入了作者的见解和经验，并展示了一些可扩展的设计最佳实践和经过验证的技术和基本原则，有助于复杂领域中软件项目的开发。战略设计的初衷是保持模型的完整性，通过战略设计将整个软件系统分解为多个有界上下文，然后针对每个有界上下文进行战术设计。

领域驱动设计（DDD）是一种软件开发方法，旨在帮助开发团队更好地理解业务需求并将其映射到软件设计中。