在运用DDD对业务进行建模的过程中，一直到进入解决方案域得到系统的限界上下文为止，其实都是不关注组织架构的。对组织架构的关注是实现域层面的事情。如果业务模型要落地，这个时候组织架构就会作为其中一个考虑的约束因素。举个简单的例子，如果是选择微服务落地，开发团队的结构就会成为微服务划分的一个制约因素。常见的情况就是如果一个限界上下文从业务上应该划分为一个微服务，但由于这一个限界上下文都必须由两个团队开发，导致这个限界上下文有可能需要拆分。这里的理论基础是康威定律：
Convey'sLaw:
"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."
“任何一个设计开发系统的组织… 其设计产生的系统结构必然会映射组织间的沟通结构”。也就是组织沟通方式决定系统设计。
这里面有问题。
康威定律的成立只是说明组织架构与系统之间必须匹配，它没有要求组织架构是合理的。不合理的组织架构也会决定不合理的系统设计。组织架构成为系统划分约束因素的前提条件是组织架构是合理的。怎么定义组织架构的合理性？回归业务，与业务匹配。
问题来了。
由于DDD也是基于业务领域的，理论上基于DDD建立的模型进行的系统设计也是合理的，它应该是真实反映业务，与业务匹配的。理论上组织架构也应该与业务匹配。所以，业务、领域模型、组织架构三者在理论上应该基本匹配，这样是最有助于组织业务发展的。一旦发生组织架构成为系统设计的制约因素导致设计必须修改的情况，证明系统设计或者组织架构存在阻碍业务发展的不合理性。这个时候，必须回过头来重新审视系统设计与现有组织架构，寻找到底是什么地方导致这种不合理性。
我们假定基于DDD的系统设计是与业务匹配的，这个时候问题就出在组织架构上。这往往是有可能的。现实情况是，经常有很多开发团队的划分不合理，导致开发效率受到严重影响。开发团队规模过大导致管理成本高，外包人员比例过高导致开发质量难以保证，人员结构不合理导致关键人员成为瓶颈，跨楼层甚至跨时区协作导致沟通成本高，这些情况在现实中经常遇到。造成这些组织问题的原因是组织架构往往是僵化的，而业务是经常变化的。组织架构的调整远远更不上业务的变化。要保证组织架构不制约业务的发展，只有调整组织架构，没有其他办法。
那怎么调整呢？团队应该如何划分才能与业务匹配呢？答案是让DDD的制约因素成为DDD要改变的目标。以DDD得到的业务领域模型为基础，审视与调整组织架构，进行团队的划分。从业务领域结构出发形成网状组织架构，并在业务发生显著变化时保持组织架构的灵活性，从反向使康威定律发挥作用。
事实上我和同事大S在给国内某大型寿险公司做转型时也做过类似的尝试。当时我们尝试运用DDD的方法划分团队，遗憾的是后面由于项目终止了，没有继续，所以无法评估效果，也无法产生进一步的洞见。希望后面有机会继续尝试。
当然，组织治理是一个很庞大的话题，不是简简单单的一个方法论就能搞定，需要考虑很多因素。但这不妨碍DDD成为一种团队划分或者组织架构治理的新的思路。
