框架DDD

简介

领域驱动设计是Eric Evans在2004年发表的Domain Driven Design（领域驱动设计，DDD)著作中提出的一种从系统分析到软件建模的一套方法论。以领域为核心驱动力的设计体系。

从领域驱动定义来看，领域驱动设计-软件核心复杂性应对之道，从Eric 定义中可以看出，领域驱动设计是为了解决复杂的软件设计，而且只是解决软件复杂性的一种方式，并不是唯一选择。另外不是所有的业务服务都合适做DDD架构，DDD适合产品化，可持续迭代，业务逻辑足够复杂的业务系统，对于系统初期业务逻辑相对比较简单的应用，传统MVC架构更具有优势，可以减少一部分认知成本与开发成本。而且领域驱动设计并不是万金油，只是解决复杂软件的一种方案，领域驱动设计本身只提供了理论思想，具体的落地方案一定是结合具体的业务场景实现的。目前市面上也有很多依据领域驱动思想落地的开源框架可以参考。

从领域驱动对应关系来看，一方面目前很多建设中台的时候大多采用DDD思想落地，DDD很多思想比如领域划分，领域事件，领域服务，边界上下文划分，充血模型，代码防腐，统一语义等等可以很好的帮助实现中台的落地，但是中台落地DDD并不是唯一选择。另一方面对于DDD的这些思想，与DDD的关系更多是聚合关系，而不是组合关系，也就是在具体应用开发中，即使采用传统的MVC架构，这些思想依然可以很好的发挥其作用。

优缺点

优点

DDD最大的好处是：接触到需求第一步就是考虑领域模型，而不是将其切割成数据和行为，然后数据用数据库实现，行为使用服务实现，最后造成需求的首肢分离。DDD让你首先考虑的是业务语言，而不是数据。DDD强调业务抽象和面向对象编程，而不是过程式业务逻辑实现。重点不同导致编程世界观不同。

• 1.面向对象设计，数据行为绑定，告别贫血模型。
• 2.优先考虑领域模型，而不是切割数据和行为。
• 3.业务语义显性化，准确传达业务规则。
• 4.代码即设计，通过领域设计即可很清晰的实现代码。
• 5.它通过边界划分将复杂业务领域简单化，帮我们设计出清晰的领域和应用边界，可以很容易地实现业务和技术统一的架构演进。

缺点