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

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

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

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

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

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

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

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

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

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

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

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

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

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

MVC

UML

UML是Unified Modeling Language的英文缩写，中文名称为统一建模语言。它是一套图形化的符号语义系统，可以说是RUP的“副产品”。但有意思的是，它的名气好像比RUP还大，而且RUP虽然已经逐渐没落了，但它却经久不衰。

UML诞生的时间，正是面向对象的软件设计（Object-Oriented Design，OOD）方法论逐步迈向C位的时代。彼时，各种编程语言、设计思想、开发流程、管理方法如雨后春笋般纷纷冒头，给实际的软件开发工作造成了很大的困扰，工程师们语言不通、思想不统一、流程不一致，导致交流想法异常困难。

什么是敏捷过程

现实世界唯一不变的就是一直在变，软件开发也是如此，新的语言，新的方法，新的思想不断出现。

除了 按“步”就班 的瀑布模型和 唯“例”是图 的RUP这两大重量级过程以外，一些小型化、轻量级的软件过程也迅速发展起来。

因为，除了那些大型的、关乎国计民生的重量级软件项目，更多的是一些面向中小型企业乃至个人的应用。例如，某个零售店的收费系统、某家公司的考勤系统、某个图书馆的借阅系统和某所大学的教务系统等。这些应用系统的需求和那些大系统相比完全不在一个数量级上，有的甚至连正式的需求文档都没有。

到1980年代末，面向对象的软件设计（Object-Oriented Design，OOD）逐渐成为业界主流。

为了统一业界诸多且混乱的面向对象方法论，并且改变瀑布模型那种僵硬的开发模式，James Rumbaugh、Grady Booch和Ivar Jacobson这三位计算机大佬创建了UML（Unified Modeling Language，统一建模语言）和RUP（Rational Unified Process，Rational统一过程）这两大利器。

1970年，一位美国计算机科学家，得克萨斯州奧斯汀市洛克希德软件技术中心主任，温斯顿·沃克·罗伊斯（Winston Walker Royce）博士发表了一篇名为《管理大型软件系统的开发》的论文。

这篇论文在业界首次提出了软件开发过程中所能采取的几种不同的项目管理方式，其中就包括了我们目前所熟知的瀑布模型、迭代模式和敏捷模式。

在温斯顿博士所处的年代，面向过程的软件开发方式是业界主流，且那时的软件行业远没有现在先进，软件项目大多数也都属于航空航天、科研制造、军事系统、能源化工等类别，工程化的特色非常明显。