背景介绍
最近公司接到一个省级的项目，而我作为项目组的成员有幸参与其中，当我们实际准备接手之前，已经有人跟我们谈过了，这个项目比较"旧"，用的技术是SSM，当时我的反应是确实"旧"点了，可当我们正式接手后被现实打脸了，如果它的"远古"来自于技术的话，那么这事情反而简单了。事实上目前架构已经无法支撑现实中复杂的业务场景，代码的可维护性与项目的运维成本大大提升。甲方要求我们在保证老系统运行稳定的前提快速研发新系统然后快速过渡，所以我们必须要重新设计，重新开发。
引出DDD
通过我们对整个项目的审查，我们最终决定使用微服务架构的形式，对现有服务或者业务进行整合，拆分成若干原子服务。然后通过微服务治理解决方案来最终完成编码。但是通过与甲方进行几次方案沟通后我们可能把问题想的简单了，事实上这次重新开发我们不仅要满足以上要求还要考虑到整个公司，准确来说不要以定制化的方式来进行落地，不要以满足某一个部门，某两个部门，而是从整个公司的业务流转或者在大范围点讲是整个行业涉及的业务范围，通过领域建模的方式来合理划分服务，通过这种设计实现代码的快速迭代与交付速度。
经过几次交涉之后我们最终的方案指向了DDD （Domain Driven Design,领域驱动设计）。
DDD 理解
DDD（Domain Driven Design,领域驱动设计）作为一种软件设计思想，它可以帮助我们设计高质量的软件模型。领域驱动设计是一种，贯穿软件生命周期的架构设计思想，每当有新需求或者需求变更时候，先回到领域模型，在基于业务进行领域模型的变更，在根据领域模型的变更指导程序的变更。无论多少变更都能从领域模型出发。而目前有效支持这种思想落地的是微服务，微服务本身也是一种架构思想，这里想表达的意思是：支持实现微服务的技术可以在DDD中得到很好应用。
DDD 实践
关于DDD的实践这里我将从三个方面简述，以下是我的见解。
领域划分
我们在做业务分析的时好像都会面临一个棘手的问题就是服务边界的划分，（这里我并未抛出领域而是先从我们比较传统的业务分析角度来进行引出）对于那些有着明显边界的服务还好，似乎总会有一些让我们有一种剪不断理还乱的思绪在我们脑海中，总会存在无法确定边界的服务可能成为我们日后业务扩展的难点系统维护的成本增加的隐患。
我们如何避免出现这种情况，或者说出现了这中情况如何理顺——领域。具备领域的思维，从技术角度来说领域可以是一堆原子服务群，亦可以是单独的原子服务；从业务的角度来说就是具有高度集中、具有边界的业务集合。 这个举个例子（似乎没那么恰当），如果把我们身体作为一个产品，那么我们在设计初期是否能准确的描述这个产品的领域，比如我们的头、四肢的位置，那么头作为一个领域其中的眉、眼、耳、鼻、口就是子域，这样一层一层的划分最终划分到原子级别
如果在软件设计初期对于领域的划分没有一个准确的把握的时候不妨使用头脑风暴法，其实很多时候我们也是这样去做，并且在发现不对的时候及时纠偏。
模型创建
关于模型创建，传统的建模一般指的数据库建模，当扩展业务的时候我们大多数思考的角度是从数据库的模型出发，只要加几个字段就能满足当前业务变更就可以。但是事实上我们并未从领域的角度分析，正确的思考应该是将当前业务回归于领域内，分析它在整个域内的影响，可能会出现的问题甚至可能对于其他领域造成的影响和对于未来的影响，将业务领域作为驱动力修改数据库模型。
似乎传统的思维有点就事论事，领域驱动则是一种从全局宏观在到微观的角度来考虑
技术支持
这里我想说下中台（领域驱动的技术中台），就如我在领域划分举的"不恰当的例子"，从功能角度出发能提供某个领域的业务支持，从软件生命周期的角度出发他就像是整体业务的粘合剂一样，是一种协调器的存在。
总结一下
这次出差的收获还是很大的，不仅解了DDD（Domain Driven Design,领域驱动设计），而且也有了重构"远古"项目的经验，以下是我的一些总结
项目程序臃肿，代码质量不高原因
-
软件的生命周期长，推到重新开发风险大，这个跟所处的行业有一定关系如：电力，银行等
-
业务复杂度越来越高，服务边界划分不清或者说服务拆分不合理，维护成本越来越高
-
最初的软件架构无法满足现实的复杂业务
辩证的看软件设计
软件设计本质是对客观世界的模拟，软件中的业务逻辑正确与否的唯一标准就是，是否与真实世界一致，从广义上来讲软件做成什么样既不由我们来决定与不由客户来决定，是由客观世界来决定，事实上软件不能完全的表达出客观世界的一切，因为客观世界太复杂，我们只能对一些简单，易懂的规则通过软件实现，以至于用户会觉得我们的软件对他们想要的表达并不是很完美，这就有了不断的需求与不断的bug。
