在理解了DDD战术设计中的那些概念以后，就可以试着整合代码了。

对于架构师或者PM来说，最核心的部分是战略设计。但对于工程师们来说，最核心的部分其实是战术设计以及它之后的代码落地，因为Talk is cheap, Show me the code。

战略分析完成之后，就到了战术分析阶段。

相对于战略设计的抽象，战术设计就比较具体了，它更多的是将业务需求映射到技术代码的层次结构上，设计上下文里都包含哪些类，这些类之间又该如何配合等。

战术设计基本上由实体、值对象、聚合、领域事件和命令、领域服务、工厂和资源库、充血模型这几个主要部分组成。

在经过业务分析后，整个系统的轮廓就被大致勾勒出来了，但这明显是一个极为粗略的轮廓，或者称为骨架。

接下来，就可以按照这个轮廓或者骨架所展示的样子，来对它做更进一步的分析和设计，赋予灵魂，填充血肉，让它符合各方的期望。

和业务分析一样，战略设计的路线图大致是这样子的。

• 根据业务分析输出的内容，从限界上下文识别开始，依次推进到上下文关系映射、统一语言和战略层面的技术决策。

• 其中，限界上下文识别和上下文关系映射可以说是整个DDD中最为重要的部分，这两个地方做出的设计，将直接决定今后系统的整体可用性、可维护性及运行效率，它是关键中的关键。

• 而战略层面的技术决策主要包含五个部分的内容，这也是决定系统运行效率的重要因素。但其实像技术栈、数据架构、治理架构和微服务的取舍很多公司都有着约定俗成的方案，或者直接采用已有的成熟经验。唯有应用架构这部分，对于不熟悉DDD的团队来说，可能就要好好斟酌一番了。

我个人的习惯是在进行业务分析时走这样的路线图。

想学习一种思想或一门技术，就需要理解这个思想或技术所赖以存在的环境，也称语境，也就是俗称的行话，或者专业术语。

本想将这些概念融入到具体案例分析之中，但结合自己的学习经历和痛点，觉得有一本小册子一样的东西可能更好，尤其是对于DDD这种复杂度稍高的设计思想来说尤其如此。一来方便集中查阅，二来也可以集中做出解释，避免出现前后不一致的混乱。

MVC