你或许以为你不需要领域驱动设计
犹记得刚刚参加工作时，是地图厂商四维图新集团旗下的一家子公司，主要从事规划测绘相关软件研发的公司。当时我的项目是为勘测设计院提供相对应的应用软件，对地理信息和规划相关的图纸信息领域的认知，几乎已经专业水平。事实上，规划设计大概和软件设计类似，有规划的设计、或无规划的设计，造成的结果几乎是天壤之别。
我们或许很容易就能设想到一个毫无规划设计的城市，纵横交错的路网、杂乱无章式的建筑布局、各种凌乱的棚户区设计，恰好象征着软件设计的无序性，也恰好体现了软件企业在经费不足、组织缺乏管理、开发者能力不足、软件随时随地想改就改时的行业现状，只能说这样的软件是最能符合当时实际劳动生产力水平的产品。
如图一所示，巴西棚户区，层层叠叠、风格迥异、密密麻麻，如果作为一个外人贸然来到这样的地方，大概很容易迷失期间、更不用说充斥在棚户区的各类毒品和黑社会。杂乱无章的建筑和街区，就像代码中错综复杂的调用链；而借助贫民区搞事的黑社会就像是代码中的异味或者bug，表面上看起来如此平静、与世无争、但是你永远也不知道啥时候会来一冷枪。
不要以为离我们很远，我们其实轻易就能写出这样的软件工程项目。不一定是“大泥球”系统，也有可能只是一些看似简单的业务系统，但内部代码逻辑，可能会复杂到令人窒息的程度。也许那个时候有个别开发者也许会试图靠自己的能力来改变局面，但是往往也会碍于屎山太大，难以下咽。
大概只有最顶级的规划设计师、耗费足够多的资源，才能将这样的软件系统进行整改。然而，即便如此，如果以后没有持续维护的手段、更好的设计、仅靠老程序员或个别架构师、盲目相信将单体服务拆分成微服务，几乎不太可能实现软件未来的可持续发展。
一个良好的软件产品的一生、或许其实是一家企业一生的真实写照。
在特定组织架构下，缺乏技术基因的组织有时候期待技术变革，却会开启新的泥坑。而那些渴望靠技术改变一切的技术专家，虽然拥有某些大厂微服务式架构、以及架构改造的经验，他们也试图通过自己的努力，为企业业务腾飞助力。而在他们过去的经验中，往往相信组织遇到的问题，用微服务一定能解决问题。然后大肆扩招，一年内从几个人的规模、扩招到数百人的规模，将原来的系统从单体服务、改良成为微服务。但是靠单枪匹马根本无力拯救大势，没有更好的业务拆分策略，就只能按照数据库的表名关系实现了最简单的拆分。架构改造并非每次都会百试百灵，有时甚至连原来的需求都包不住，毕竟只能看到用户界面层外观上的表面逻辑，而隐藏在业务中的那数十万行代码，哪怕包含了企业最有价值的经验财富，也由于代码过于混乱，最终抛弃在源代码管理器中，堪称化神奇为腐朽。
老系统改造也好、新系统开发也好，毫无疑问，我们最容易相信的其实是老程序员经验，而程序员们掌控系统的方式，就是靠数据库建模来驱动软件开发的古老模式，而且几乎都是面向过程式的代码，这些代码的流程几乎一模一样，只需简单的按照步骤，一步步套模式，轻易就能学会。
1、查看用户界面，定义需要绑定到界面的模型和层级结构。
2、设计数据库，不管什么类型的项目，先根据客户提供的业务表单、将其转化成实体关系（ER图）、然后建立对应的代码模型。有可能使用专业软件设计ER图，也有可能会使用Navicat软件设计ER图。
3、设计接口，然后把数据拼凑成用户界面层所需的对象。
4、代码层次结构为传统的三层架构，严格按照用户界面层、业务逻辑层、数据访问层进行设计，有时候会引入依赖注入框架，实现不同层次间的解耦。
但是有时候程序员不会严格区分需要编写的代码，究竟是属于哪个层次应该囊括的内容。于是毫无疑问，如果代码是为了实现用户界面上某些数据绑定操作，代码就往用户界面层写；或者代码是为了实现从数据库中抽取某些复杂数据、并构造成满足用户表现层逻辑的查询对象，那么就可以看到数据访问层代码中那些臃肿的SQL语句或查询方法。
正如“罗马不是一天建成的”，屎山也同样如此。这样的写法在代码刚刚编写之初并没有问题，只是随着业务变化、时间的积累、程序员的水平、方法重构、新技术新组件的引入，代码将成为屎山。
这时，高级程序员们的价值，就在于他如何能够在屎山中快速找到bug、并解决问题的能力，这大概是一种不能复用、不可再生的能力，因为永远有让人看不懂的垃圾代码，而且每家企业都有自己的特点，不同企业间往往不能循环利用。我一位朋友经常吐槽，他感觉自己的价值就是守住公司那份拥有8年历史的古老代码，以便其他程序员在进行代码修改时，不会引发莫名其妙的bug让系统无法运转。
在现代软件工程学的教科书中，都会指出面向对象是解决软件复杂性的方法，但实际上掌握这种方法的开发者并不多。由于开发者普遍缺乏抽象化思维，所以面向数据库、面向过程式的编程习惯能够成为业界主流，并非时代的倒退，而仅仅只是在短期效率和长期维护性上，被迫做出的艰难选择。
假设我们设计出的符合三层架构的系统结构图简化后，如下图所示：
1、会定义两种对象，分别是是面向UI层的模型（DTO)和数据实体（Entity）。在领域驱动设计中，将这两种称为所谓贫血模型，贫血模型，只有赋值器Set和取值器Get，（在Java里面会使用POJO 这个名词来定义）。贫血模型是为了作为保存状态或传递对象而存在，他并非按照实际用例场景对某类具体事务的抽象、也没有与对象相关的行为。
2、定义数据访问层来实现数据的持久化、或者从持久层实现数据的创建过程。数据访问层存在的目的是为了构建上述贫血模型对象，这种访问机制被成为“事务脚本”。事务脚本与对象行为割裂，而且容易导致异味产生。
3、与用户行为相关的操作割裂的存放在不同层。有的可能放在用户界面层、有的可能放在数据访问层、有的可能放在业务逻辑层，造成了领域知识的丢失。
4、用户界面层使用接口作为外观或者一种行为、开发者会使用自己独立的风格习惯来定义这种行为，就容易造成术语和规则不统一，也会为后期产品的维护迭代造成问题。
5、现在的软件设计，往往要求输出一份高保真的原型图、也会按照敏捷项目管理的流程对这份原型图建立持续更新的机制，确保原型图是需求的具体表达，但是产品语言并非统一语言，也许产品语言具有业务含义，但是由于不能指导开发者进行接口、类、持久层的设计，造成了代码与需求的割裂。在张逸老师的《领域驱动战术实践》提到他曾经使用dimension和metric两种不同的对象来定义一个维度对象，为代码造成了不必要的麻烦。我也曾经在一个项目，遇到过产品术语未能澄清，导致开发中使用style和theme两种截然不同的定义来定义与“风格”相关术语，为代码引入了不必要的纠结。
领域驱动设计引入了以下概念，但是我们无需在这篇文章中深刻理解这些概念的具体含义，我们只需知道，有这个东西。当我们开始按照领域驱动设计的方法设计一个系统时，按照前人整理的领域驱动的sample，往往就会将概念融汇贯通，达到更好的理解效果。
1、统一语言：定义好产品原型，需要建立统一语言。这是一种在内部和外部都能使用的规范化用语，包括UML、适当的图、一致性的描述、以及专业术语和术语对应的英文描述。
2、实体：在领域中可以通过标识进行唯一值定位的对象。
3、值对象：在领域中，从其他领域或某个实体中分离出只包含某些特定属性的对象。由于不具备唯一性特征，往往无需用于数据持久化。
4、聚合、聚合根：将具有相关性的对象聚合在一起，并以聚合根的形式统一对外提供访问方法和属性字段成员。
5、限界上下文：领域包含核心领域、子域和通用子域，而限界上下文则是一个具体业务的流程。每个限界上下文独立于其他限界上下文而存在，独立演进、功能完备。限界上下文的识别充满技术含量。
6、领域服务：包括仓储服务和工厂服务，前者负责实现对象与数据库的操作过程、封装了一系列数据库操作的方法；后者则侧重于对象的创建过程。个人认为从三层架构演进到领域驱动架构过程中，仓储服务是最接近于数据访问层的逻辑，也是让大部分领域驱动架构最终又回归到三层架构的一种通病。从对数据访问层中抽出对象、行为、数据访问，是战术设计的关键步骤。
领域驱动设计引入了一堆新的架构形式，包括经典的四层架构、EDA（事件驱动架构）、CQRS架构（命令查询职责分离）。而由于Evans的原书没有过分讨论如何识别领域，后来又有许多大佬在他的基础上进行了完善，提出了许多方法，包括名词、形容词、动词建模法、事件风暴、四色建模等方法，限于篇幅，且听下回分解。
领域驱动设计，或许是解决这些问题的一剂良方，但也或许是开启了暗黑世界的大门。
概念晦涩难懂、程序员们不愿意开始思维变革、技术上可能存在不预期的坑、都可能让新方法的实践陷入一滩烂泥。还有许多人以为自己看懂了领域驱动设计（包括笔者），在往项目中运用时，总是有意无意的会被过程式代码的思维定式控制，让架构回退到三层架构。
由于微服务架构的兴起，让复杂系统的开发维护成为大家普遍关心的问题，使得Eric Evans于十五年前提出的这套理论，在今天绽放出了新的光芒。当然领域驱动设计仅仅只是众多面向对象编程的一种实践，通过领域驱动设计将UML等方法灵活的运用其中，通过打破原有数据库关系建模给代码造成的桎梏，让开发者能够真正的实现面向对象编程。
然而思维模式的转换并非易事，从过程式代码中，抽离出与对象有关的行为，远比理解这几个概念要复杂，这需要大量经验的积累。
毋庸置疑，数据库建模驱动软件开发具有速度快、学习成本低的显著特点，在许多项目中，能在短期内可以给开发者带来许多便利；而应用领域驱动设计，则可以在更长的维护周期内，给软件维护带来实质性好处。
两种不同类型的开发模式，根据企业实际出发进行选择，还只是开始，但能真正运用好领域驱动设计或者UML、面向对象设计这种软件工程的美学思维来改造我们的系统，让系统绽放出更加璀璨的光芒，这才是软件设计的乐趣所在。
长按订阅更多精彩▼
如有收获，点个在看，诚挚感谢
标签:
