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

【51CTO.com原创稿件】随着微服务理论的盛行，沉寂了近二十年的DDD领域驱动设计的价值逐渐被越来越多的公司认可。

文章图片
图片来自包图网
但是DDD作为纯方法论，在实际应用中因缺乏类似框架的强约束性，如何有效指导业务落地实施，尤其是复杂系统架构的优化改造，都对研发团队提出很高的要求。
采购平台则通过溯源演进重放的方法，以“上帝视角”重新审视整个系统架构和业务发展的历程以及重要节点，以演进重放的方式进行领域模型设计。
一方面使复杂系统改造有了很好的切入点，另一方面使系统设计天生具备演进属性，适应当下业务的同时也能更好的兼容未来业务的发展。
根据熵增定律，一切事物如果不加以约束都趋向从有序变为无序。系统作为一个独立个体，其熵增趋势也是无法避免的。
业务的横向拓展和纵向深耕，架构演进和技术创新都会导致系统复杂性越来越高。
毕竟个人的认知和接受能力是有上限的，当系统的复杂性超出团队大多数人的认知上限时，系统的任何一点微小的优化或改动，都会让研发团队疲于奔命，也会给系统的稳定性带来很大的风险或隐患!
所以提升开发效率和系统稳定性成为技术研发团队绕不开且必须解决的问题。
事件
通过对采购平台系统发展历程和重要节点的不断审视，发现导致系统复杂性的主要原因还是业务的复杂性。
系统架构设计中如果不能很好的解决业务领域的复杂性，技术架构的优化和演进再好也于事无补。
采购平台自15年搭建伊始，业务横向方面从最初单一的电器业态，逐步拓展红孩子，百货再到近几年的小店，迪亚，家乐福等大快消业态。同时纵向对电器业态的深耕，如样机，不良品，换异型等也在同步进行。

文章图片
业态，操作模式，经营模式，业务模式等等相互穿插组合带来了业务的灵活多变的同时，也带来系统复杂度几何级上升。
此时高效的开发效率更是无从谈起，很难对业务的发展提供高效支撑，随之而来的业务的埋怨和领导的不理解也给开发团队带来很大的心理负担，进而影响团队稳定性……环环相扣陷入恶性循环的泥潭。
如何破开困境?倡导保持概念完整性的领域驱动设计是个不错的选择。 DDD关注于精简的业务模型和实现的匹配，其作为方法论指导系统架构设计，是解决业务领域复杂性的利器。
通过领域驱动设计模式促使研发团队将业务模型作为项目沟通的核心，使成员之间更容易理解彼此之间的工作，大大提升团队沟通效率。
【老板要做DDD改造，我现在慌得一比】领域模型的高内聚低耦合，大大降低不同业务模块之间的影响有效提升系统稳定性，同时领域驱动设计倡导概念完整性，注重模型和实现的匹配使系统更易于理解和扩展。

文章图片
挑战点(难点)
虽然领域驱动设计是个不错的指导方法论，也正因为是通用的理论，在具体项目的落实中，因不存在相同业务的系统，即使相似业务的系统因规模和产品生命周期差异，也只有一般意义上的参考价值。
所以都需要面临如何进行领域建模的快速切入，以及预防模型在实现层面的腐化等诸多挑战点。
主要体现在以下几个方面：
①逻辑复杂，无从下手。系统经过日积月累的迭代优化，新的业务模块和功能点与日俱增，且成发散趋势。