一、易于腐化的软件设计

犹记得刚刚参加工作时，是地图厂商四维图新集团旗下的一家子公司，主要从事规划测绘相关软件研发的公司。当时我的项目是为勘测设计院提供相对应的应用软件，对地理信息和规划相关的图纸信息，几乎已经专业水平。事实上，规划设计大概和软件设计类似，有规划的设计、或无规划的设计，造成的结果几乎是天壤之别。

我们或许很容易就能设想到一个毫无规划设计的城市，纵横交错的路 、杂乱无章式的建筑布局、各种凌乱的棚户区设计，恰好象征着软件设计的无序性，也恰好体现了软件企业在经费不足、组织缺乏管理、开发者能力不足、软件随时随地想改就改时的行业现状，只能说这样的软件是最能符合当时实际劳动生产力水平的产品。

我们来看看这种数据库建模的开发流程中的输出成果：

1、会定义两种对象，分别是是面向UI层的模型（DTO)和数据实体（Entity）。在领域驱动设计中，将这两种称为所谓贫血模型，贫血模型，只有赋值器Set和取值器Get，（在Java里面会使用POJO 这个名词来定义）。贫血模型是为了作为保存状态或传递对象而存在，他并非按照实际用例场景对某类具体事务的抽象、也没有与对象相关的行为。

2、定义数据访问层来实现数据的持久化、或者从持久层实现数据的创建过程。数据访问层存在的目的是为了构建上述贫血模型对象，这种访问机制被成为“事务脚本”。事务脚本与对象行为割裂，而且容易导致异味产生。

3、与用户行为相关的操作割裂的存放在不同层。有的可能放在用户界面层、有的可能放在数据访问层、有的可能放在业务逻辑层，造成了领域知识的丢失。

4、用户界面层使用接口作为外观或者一种行为、开发者会使用自己独立的风格习惯来定义这种行为，就容易造成术语和规则不统一，也会为后期产品的维护迭代造成问题。

5、现在的软件设计，往往要求输出一份高保真的原型图、也会按照敏捷项目管理的流程对这份原型图建立持续更新的机制，确保原型图是需求的具体表达，但是产品语言并非统一语言，也许产品语言具有业务含义，但是由于不能指导开发者进行接口、类、持久层的设计，造成了代码与需求的割裂。在张逸老师的《领域驱动战术实践》提到他曾经使用dimension和metric两种不同的对象来定义一个维度对象，为代码造成了不必要的麻烦。我也曾经在一个项目，遇到过产品术语未能澄清，导致开发中使用style和theme两种截然不同的定义来定义与“风格”相关术语，为代码引入了不必要的纠结。

四、领域驱动设计是什么h1>

领域驱动设计引入了以下概念，但是我们无需在这篇文章中深刻理解这些概念的具体含义，我们只需知道，有这个东西。当我们开始按照领域驱动设计的方法设计一个系统时，按照前人整理的领域驱动的sample，往往就会将概念融汇贯通，达到更好的理解效果。

1、统一语言：定义好产品原型，需要建立统一语言。这是一种在内部和外部都能使用的规范化用语，包括UML、适当的图、一致性的描述、以及专业术语和术语对应的英文描述。

2、实体：在领域中可以通过标识进行唯一值定位的对象。

3、值对象：在领域中，从其他领域或某个实体中分离出只包含某些特定属性的对象。由于不具备唯一性特征，往往无需用于数据持久化。

4、聚合、聚合根：将具有相关性的对象聚合在一起，并以聚合根的形式统一对外提供访问方法和属性字段成员。

5、限界上下文：领域包含核心领域、子域和通用子域，而限界上下文则是一个具体业务的流程。每个限界上下文独立于其他限界上下文而存在，独立演进、功能完备。限界上下文的识别充满技术含量。

6、领域服务：包括仓储服务和工厂服务，前者负责实现对象与数据库的操作过程、封装了一系列数据库操作的方法；后者则侧重于对象的创建过程。个人认为从三层架构演进到领域驱动架构过程中，仓储服务是最接近于数据访问层的逻辑，也是让大部分领域驱动架构最终又回归到三层架构的一种通病。从对数据访问层中抽出对象、行为、数据访问，是战术设计的关键步骤。

领域驱动设计引入了一堆新的架构形式，包括经典的四层架构、EDA（事件驱动架构）、CQRS架构（命令查询职责分离）。而由于Evans的原书没有过分讨论如何识别领域，后来又有许多大佬在他的基础上进行了完善，提出了许多方法，包括名词、形容词、动词建模法、事件风暴、四色建模等方法，限于篇幅，且听下回分解。

两种不同类型的开发模式，根据企业实际出发进行选择，还只是开始，但能真正运用好领域驱动设计或者UML、面向对象设计这种软件工程的美学思维来改造我们的系统，让系统绽放出更加璀璨的光芒，这才是软件设计的乐趣所在。