老板要做DDD改造，我现在慌得一比( 二 ) 【51CTO.com原创稿件】随着微服

再加上即使同业态下业务的深耕也有很多个性化需求，功能点相互穿拆耦合的现象非常普遍，千头万绪很难梳理。需要有个适合自身业务，行之有效的方法去指导辨别合适的切入点。
②能力差异，边界难定。领域驱动设计使开发团队从面向数据库编程转为面向领域编程，一切都要求从业务角度出发，对团队成员业务理解能力要求大大提升。
实际上团队成员的能力总是有差异的，其导致的理解偏差最终会逐渐反应到实现层，进而影响整个业务领域蓝图。
特别是在领域边界的建立，模糊的有交集的领域模型，最终会腐化整个架构。这就需要有契合业务特性，简易的界定方式，帮助团队成员快速清晰的确认领域边界。
③业务细化，粒度难分。明确了领域范围也就是限界上下文，业务域做了合理的划分也不代表领域驱动设计就会水到渠成。
随之业务发展，原业务域或者子域可能又出现垂直细分的需求，细分的业务概念是否需要反应到业务领域蓝图也是一个需要重点考虑的问题。
业务概念的完整性和模型精简之间权衡的度的把握，同样需要有个简单易行的标准。
分析与解决过程
针对上述问题，主要分析和解决方案对应如下：
①以始为本，回放演进
任何复杂的事物都是从简单演化出来的，复杂的系统亦然。纵览采购平台的演进历程，系统搭建初期，无论是业务模式还是系统规模都是最简单和最小的。
所以通过复盘溯源的方式以系统搭建初期业务和系统规模为基线，进行初始化领域模型搭建更具可行性。
一方面业务规模小，更容易梳理出业务主线。加上初期各业务域之间很少或不存在交叉情况，建立领域模型相对简单也方便入手。
另一方面初始领域模型建立后，再以业务和系统的实际的演变过程对初始领域模型进行丰富和优化，最终形成一个边界清晰的完整的业务领域蓝图。

文章图片
这一切都是在复盘过往业务发展和系统演进的基础上进行的，贴合了业务和系统的发展曲线。
从概率的角度上看，用该方法完善的领域模型比单纯依靠经验而建的模型更能好的契合当前业务发展和兼容未来业务的变化。同时以上也都符合一个好的架构的“简单，合适，演进”特征。
②作用范围，领域定界
提及领域驱动设计离不开“核心域”“聚合根”“实体”“值对象”“限界上下文”等， DDD的各类文档资料对上述名词都有很明确的定义和解释。
但是实际项目的落实中，仍然需要一个简易可行的界定方法，为领域驱动设计在团队内部实施和演进扫清障碍。
“易则易知，简则易行”简易可行的方法才能更容易被团队成员理解和接受。
结合采购平台本身的业务特性，将采购执行链路上产生的各种类型单据以及交互进行梳理，如订单，预约单，作业指令，收发货等实体化后作为一个对象，以此对象作为聚合根，凡是以该对象为主体的作用范围都归于一个领域。
一旦该对象在某个环节的业务逻辑中失去“主角”光环，则需要根据实际业务确定新的“主角”进而决定是新建领域还是转到已存的别的领域。

文章图片
③维度固化，细化剥离
维护业务概念的完整性是衡量设计好坏的一个重要的参考指标。好的设计从代码层面清晰展现业务领域蓝图且易于理解，同时又能很好的隔离不同领域相互之间的影响。