老板要做DDD改造，我现在慌得一比( 三 )

实际项目中往往存在很多因业务需要在某一场景下进行细分的情况，按照维护业务概念完整性的要求就需要将细分场景进一步独立进行隔离解耦。
但过多的细分场景增加了开发工作量也模糊了业务领域蓝图，同时加深了对业务整体的沟通和理解难度。
如采购平台实际的收发货业务场景，最初根据业务分类按照采购入库，退厂出库，调拨出库，调拨入库等进行分类场景处理。
后期随着业务的拓展，采购入库场景下进一步按类型维度细分出换异型入库，不良品返厂维修入库等完全个性化的处理逻辑。
根据链路上下游系统交互情况，以及团队内部对该业务域的认知，权衡后确定的原则是，以收发货业务分类进行领域蓝图的展现，以此作为该业务域下维护概念完整性的唯一且不变的维度。
特定业务分类下进一步按类型细化场景，作为一个子域，业务也独立并以策略模式归集于上一层的业务分类领域。

文章图片
方法论(正向)
领域驱动设计作为指导架构设计的一种有效思想，对复杂逻辑的业务系统的重构和建设提供了很好的解决方案。
但再好的设计也必须通过实现层展现，实现层质量又严重依赖开发团队的个人能力。
“简易可行，契合业务”的方法和原则还是很有必要的，这是设计推行和架构防腐的很有效的手段。
但同时也要看到领域驱动设计并不是解决系统复杂性的银弹。对症则是良药，为了DDD而DDD则可能最终变成毒药。
作者：胥磊
简介：苏宁易购供应链BU采购管理研发中心采购中台技术负责人，对复杂业务系统架构的优化和拓展有一定的经验。前后负责过苏宁采购平台的搭建，向采购中台演进以及DDD改造的技术架构设计。
编辑：陶家龙
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】