DDD在解耦中有哪些作用？

DDD（Domain Driven Design，领域驱动设计），对于避免Stamp Coupling很有帮助。

在DDD中，最关键的一个概念是限界上下文，每个上下文内的概念是完整的，上下文是闭合的。比如A，B两个上下文都有顾客 的概念，但彼此没有任何关系。

只有在上下文集成的时候，概念间才会出现转换，然而这种转换只发生在集成的部分，即耦合是控制在胶合地带的。

同时，上下文间定义了映射关系，在上下文的关系中，又定义了上游和下游。下游需要理解上游的概念，而上游不需要理解下游的概念，甚至不应该知道下游的存在。

• DDD中上下文的关系有好几种，不是每一种都能明确上下游，我推荐尽可能使用有上下文定义的关系，比如“客户-供应商”关系

前面的例子里

，取款的顾客是下游，而银行是上游，顾客需要理解银行的那些概念，诸如，定期账户、活期账户、取款等等，而银行不关心顾客的私人生活。

举个更实际的例子，销售上下文中有订单这个概念，用户提交一个订单，然后销售上下文把订单给到生产上下文，生产上下文去完成拣货打包，这就构成了Stamping Coupling。

如果按照DDD的思想，首先，生产上下文中，不会有订单的概念，只会有生产单的概念，所以，你给它一个订单让它去生产，它无法接收。其次，这种场景，订单上下文是下游，它应该负责把订单转换为上游生产上下文的生产单，生产上下文对此甚至是不知情的，这就变成了Data Coupling。

• 如果想让下游和上游也保持一定的独立性，可以使用DDD中的防腐层的概念，这个有点类似我们上一篇中讲的DIP原则。很多面向对象的原则在更大尺度的系统设计层面也是适用的。

如果想让下游和上游也保持一定的独立性，可以使用DDD中的防腐层的概念，这个有点类似我们上一篇中讲的DIP原则。很多面向对象的原则在更大尺度的系统设计层面也是适用的。