【.com原稿】随着微服务理论的盛行，沉寂了近二十年的DDD领域驱动设计的价值逐渐被越来越多的公司所认可。图片来自宝图网，但DDD作为一种纯粹的方法论，在实际应用中缺乏类似框架的强约束。如何有效地指导业务实施的实施，尤其是复杂系统架构的优化改造，对研发团队提出了很高的要求。采购平台通过溯源、演化、回放的方式，以“上帝视角”重新审视整个系统架构和业务发展流程及重要节点，并以演化、回放的方式设计领域模型。一方面为复杂系统的改造提供了良好的切入点，另一方面使得系统设计具有内在的演进性，适应当前业务，更好地兼容未来业务发展。根据熵增定律，如果任其发展，一切都会从有序变为无序。作为一个独立的系统，系统的熵增趋势是不可避免的。业务的横向扩展和纵向深耕，架构的演进和技术的革新，都会导致系统的复杂度越来越高。毕竟个人的认知和接受是有上限的。当系统的复杂度超过了团队中大多数人的认知极限时，任何对系统稍有优化或修改都会让研发团队疲惫不堪，同时也会影响系统的稳定性，带来极大的风险或隐患！因此，提高开发效率和系统稳定性成为技术研发团队无法回避和必须解决的问题。事件通过对采购平台系统的开发流程和重要节点的持续审视，发现导致系统复杂的主要原因是业务的复杂性。如果在系统架构设计中不能很好地解决业务领域的复杂性，技术架构的优化和演进再好也于事无补。自2015年采购平台成立以来，业务横向方面从最初的单一电器业务，逐步扩展到红孩儿、百货，再到小卖部、迪亚、家乐福等国内大型快消业务。最近几年。与此同时，电工行业的垂直深耕，如样机、不良品、异形更换等也在同步进行。业态、运营模式、商业模式、商业模式等的交织组合，带来了业务的灵活性和变化，也带来了系统复杂度的几何级数增长。这时候，高效的开发效率无从谈起，难以为业务发展提供高效的支持。随之而来的业务抱怨和领导的不理智也给开发团队带来很大的心理负担，进而影响团队。稳定……链条环环相扣，陷入恶性循环的泥潭。如何突破困境？提倡保持概念完整性的领域驱动设计是一个不错的选择。DDD侧重于流线型业务模型和实现的匹配。作为指导系统架构设计的方法论，是解决业务领域复杂性的利器。通过领域驱动的设计模式，鼓励研发团队将业务模型作为项目沟通的核心，让成员更容易理解彼此的工作，大大提高团队沟通的效率。领域模型的高内聚、低耦合，可以大大降低不同业务模块之间的影响，有效提高系统的稳定性。同时，领域驱动设计提倡概念的完整性，注重模型与实现的匹配，使系统更易于理解和扩展。挑战（困难）虽然领域驱动设计是一个很好的指导方法论，但也是因为它是一个通用理论。在具体项目实施中，由于没有同一个业务的系统，即使是业务相似的系统，也会因为规模和产品生命周期的差异而存在差异，也只是一般意义上的参考价值。因此，我们都需要面临很多挑战，比如如何快速切入领域建模，防止模型在实现层面的腐败。主要体现在以下几个方面：①逻辑复杂，无从下手。系统随着时间的推移不断迭代优化，新的业务模块和功能点日益增多，并且日趋分化。此外，即便是深耕同行业的业务，也存在很多个性化需求，功能点相互交织脱钩的现象十分普遍，纷繁复杂的线索难以梳理。需要有适合自己业务的有效方法来引导，确定合适的切入点。②能力不同，边界难定。领域驱动设计使开发团队从面向数据库的编程转变为面向领域的编程。一切都需要从业务角度出发，大大提高团队成员的业务理解能力。事实上，团队成员的能力总是不同的，由此产生的理解偏差最终会逐渐体现在执行层，从而影响整个业务领域的蓝图。特别是在领域边界的建立上，模糊和交叉的领域模型最终会腐蚀整个架构。这就需要一种简单的定义方法，既符合业务特点，又能帮助团队成员快速清晰地确定领域边界。③业务细化，粒度难以区分。明确了领域的范围就是限界上下文，合理划分业务领域并不意味着领域驱动设计就自然而然。随着业务的发展，原有的业务领域或子领域可能需要进行垂直细分。细分后的业务理念是否需要体现在业务领域的蓝图中，也是需要考虑的问题。商业理念的完整性和模型的简化之间权衡程度的把握，也需要一个简单易行的标准。分析与解决过程针对以上问题，主要分析与解决方案对应如下：①从头开始，重演演化任何复杂的事物都是从简单演化而来的，复杂的系统也是如此。从采购平台的演进来看，在系统建设的初期，无论是业务模型还是系统规模都是最简单和最小的。因此，以初始业务和系统规模为基线，通过评审和溯源的方式初始化领域模型构建更具可行性。一方面，业务规模小，更容易梳理主业。另外，前期各个业务领域之间几乎没有交集，建立领域模型也比较简单方便。另一方面，在初始领域模型建立后，根据业务和系统的实际演进过程，对初始领域模型进行丰富和优化，最终形成一个完整的、边界清晰的业务领域蓝图。这一切都是基于对过去业务发展和系统演进的回顾，符合业务和系统的发展曲线。从概率的角度来看，通过这种方式完善的领域模型比单纯依靠经验建立的模型更能贴合当前业务发展，兼容未来业务变化。同时，以上这些都符合一个好的架构“简单、合适、进化”的特点。②作用范围、领域划定提到领域驱动设计离不开“核心领域”、“聚合根”、“实体”、“值对象”、“限界上下文”等DDD的各种文档资料对上述术语Definition和Explanation有非常明确的定义。但是在实际项目的实施中，仍然需要一种简单可行的定义方法，为领域驱动设计在团队内部的实施和演进扫清障碍。“易知易行”，简单易行的方法更容易被团队成员理解和接受。结合采购平台自身业务特点，梳理采购执行环节产生的各类单据和交互，如订单、预约单、作业指导书、收发货等，物化后作为对象，并以该对象为聚合根，所有以该对象为主体的作用域都属于一个域。一旦对象在某个环节的业务逻辑中失去了“主角”的光环，就需要根据实际业务确定新的“主角”，再决定是新建域还是转移到另一个已有域。③维度固化、细化、分离，保持商业理念的完整性，是衡量设计好坏的重要参考指标。好的设计从代码层面清晰地展示了业务领域的蓝图，并且易于理解。同时，它可以很好地隔离不同域的影响。在实际项目中，往往有很多情况需要在某个场景下对业务进行细分。为了保持业务理念的完整性，细分场景需要进一步独立隔离解耦。但过多的细分场景增加了开发工作量，模糊了业务领域的蓝图，同时加深了业务整体沟通和理解的难度。例如采购平台的实际收发货业务场景，最初是按照采购入库、出厂、出库、转入库的业务分类进行处理的。后期，随着业务的拓展，进储场景进一步细分类型和维度，具备异形仓调换、残次品返厂返厂入库等完全个性化的处理逻辑。根据链路上下游系统的交互，以及团队内部对业务领域的认知，权衡后确定的原则是根据收发货业务的分类展示领域蓝图，作为维护业务领域下概念完整性的方法的唯一不变维度。在具体业务分类下，场景按类型进一步细化。业务作为一个子域，在策略模式中也是独立的，集合在上层的业务分类域中。方法论（正向）领域驱动设计作为指导架构设计的有效思想，为复杂逻辑业务系统的重构和构建提供了很好的解决方案。但再好的设计也必须通过实现层来呈现，而实现层的好坏很大程度上取决于开发团队的个人能力。“简单可行，适合业务”的方法和原则还是很有必要的，是设计实施和结构防腐非常有效的手段。但同时，我们也必须看到，领域驱动设计并不是解决系统复杂性的灵丹妙药。症状是良药，为DDD而DDD可能最终成为毒药。作者：徐磊简介：苏宁易购供应链BU采购管理研发中心采购中心技术总监，对复杂业务系统架构的优化和扩展有一定的经验。先后负责苏宁采购平台建设、采购平台演进及DDD改造技术架构设计。编辑：陶佳龙征稿：如有意向投稿或寻求报道，请联系editor@51cto.com【原创稿件请注明原作者和出处为.com，合作网站转载】
