再谈 DDD 是银弹吗？
在 DDD 是银弹吗？ 中，D瓜哥分享了关于领域驱动设计的三个问题。最近在读一本书 《架构设计2.0：大型分布式系统架构方法论与实践》。（这本书还不错，推荐）这本书中，花了两个章节的篇幅，重点谈论了领域驱动设计。引用书中的观点，结合个人开发经验，再来谈一谈 DDD 是否是银弹？
软件建模的困难
首先，必须面对的一个事实是：软件建模，困难重重；尤其是对于复杂业务的建模，更是难上加难。
对于复杂业务的软件开发，其生命周期大概分为如下五个阶段：
确定业务目标和业务价值。
比如某消费信贷业务。
目标被拆解成一系列核心功能点。
比如消费信贷下的授信、交易、账务等。
围绕这些功能点定义业务流程、业务规则，以及整个过程设计什么样的业务数据或业务对象。
比如账单分期金额必须大于 100 元。
领域建模。
比如对账务系统进行建模。
基于领域模型做技术架构的设计。
比如是否要做读写分离？是否要做分库分表等？
软件建模的本质是找出现实世界中的“不变形”。但是，现实世界中，唯一不变的就是这个世界在不断变化！所以，建模的过程也是一个反复的过程。如下图：
几乎不存在稳定的领域模型
我们追求一个稳定的领域模型，但是，现实却给了我们重重一击：稳定的模型几乎不可能做到。原因如下：
意识问题。
在消费、业务及产品等关注的是业务流程。唯独开发人员要将业务流程转化成业务模型。
现实世界的复杂性。
现实业务是复杂的，建模只是抽取了一个现实业务某一时刻的业务形态。但是，业务形态会有变化的，比如取现前期不可分期，后期业务迭代可能就会运行进行分期。
迭代速度。
互联网公司要求“小步快跑，快速迭代”。这与模型的稳定其实是矛盾的。为了业务的迭代速度，只能牺牲模型的稳定性，为了赶工期，只能在模型上不断打补丁。
火候的掌握。
开发人员的设计能力无法一蹴而就。既需要思考，又需要反复练习。在快速的业务迭代和人员流动下，开发人员根本没有时间锤炼自己的设计能力。那么，对于设计火候的掌握，也就很难达到理想中的水平。
领域驱动设计的困难
书中总结了实施领域驱动设计的五个困难，D瓜哥逐一谈谈自己的看法：
领域驱动设计本身只是一套思维方法，而不是要严格执行的标准，所以其本身弹性很大。
这个问题，D瓜哥在上一篇文章中已经讨论过了。弹性太大，就有太多值得商榷的地方，也许初次开发，还可以按照某个人的想法一以贯之。但是，随着参与维护的人员增多，每个人都会不由自主地会带入个人的一些想法，各种想法的碰撞，必然就会引入代码结构的混乱。
思维方式的转换很难。
绝大多数面向业务的开发人员，尤其是 Java 开发人员，对三层架构已经有根深蒂固的认识。思维方式已经被打上深深的烙印，想要改变，坦白讲，极其困难。尤其是，没有一个同一个的标准和广泛认可的实现范例，完全靠摸着石头过河，必然会“一千个读者，就有一千个哈姆雷特。”
领域驱动设计的实施需要强大的技术基础实施来保证。
D瓜哥私以为这个倒不是什么问题。针对技术问题，尤其是一些共性问题，都有成熟的解决方案。只要能合理搭积木，就可以解决相应的问题。
大量存量的老系统，重构成本大于收益，没有重构动力。
编程第一准则：代码能跑就不要动。重构引入的问题谁来解决？重构带来的事故谁来负责？这个时候必须祭出这张图了：
图 2. 代码能跑就不要动当然，私以为不是程序员反感重构代码，更多是因为下面这个因素。
在互联网的快速开发迭代面前，很少有人可以静下心来在软件方法论层面去精雕细琢，更多的是快速堆砌功能，完成业务需求开发。
业务的快速迭代，导致根本没有时间让开发人员去优化代码。可口的饭菜需要恰当的火候和足够的时间，优雅的软件建模也需要恰当的火候和足够的时间。精心地软件建模需要三个月，业务让你一个月上线，而且还是加班加点才能干完。结合实际来看，绝大多数情况都会想业务妥协吧？！
领域驱动设计的出路
书中的观点是做个折中：在宏观层面，遵循领域驱动设计的方法论；在微观层面，不严格遵循领域驱动设计的方法论。
D瓜哥是这样理解的：可以利用领域驱动设计里面的限界上下文的思想，把领域做个分割，划分成业务更聚合的子域。在子域内部，提炼出统一语言，来规范业务、产品和开发沟通的业务术语。在子域交互的接口层面，进行精心设计，精雕细琢。至于子域及接口的内部实现，就交给开发团队自己决策，只要满足对应的技术指标（比如每秒要支撑多大的访问量）即可。
在部门内部讨论时，D瓜哥还给出了一个更具操作性和落地性的方案：现实面临的问题是代码冗余，技术欠债，不容易维护。先放下关于领域驱动设计的无谓讨论，利用每一次开发的机会，把冗余代码删除，把代码重构和优化，一步一步地精炼代码，即使不谈领域驱动设计，相信在逐步重构和优化下，技术欠债会逐渐弥补，可维护性也会逐步提高。
