前面列举了一些我自己踩过或见过的坑，本篇里再从从正面说一下体会。
DDD 最适合的场景是重构
无论是重构自己团队的旧系统，还是加入新公司后重新写一套原公司的老系统，都合适。因为这时你非常清晰地知道这个系统需要做成什么样子，这个领域是什么样子，限界上下文要怎么拆分。DDD中最难的就是确定领域层，而这一步你已经成功了一大半。
DDD对团队配置有一定要求
正如我的“坑四”里说的，它要求技术团队有最起码的技术和业务理解能力，并且有愿意主动去了解业务的心态。
它也要求业务团队对技术有足够的尊重，并有意愿主动配合学习新技术。
它也对整个系统架构的设计者的业务和技术能力有更高的要求，因为一旦领域层的设计有缺陷，一层层的调用会放大这些缺陷。
确定限界上下文的个人心得
以业务为主，技术实现为辅，团队协作方式主动适应领域实现。
为什么是业务为主？业务逻辑一般是不太容易变通的，但技术实现上可变通的空间很大。比如将一个服务拆成两个服务后，无法像原来一样join两个表一次出结果，但可以分别在两个表里查询后在程序里进行join, 最终输出的结果是一样的。这就是通过技术实现上的变通来主动适应业务逻辑。
为什么技术为辅？为了配合业务逻辑，技术实现上是可以变通，但这个变动往往是有代价的。因此需要衡量技术上的代价能不能接受。比如上面的例子里，把一次join变成两次查询，就是非常小的性能代价，可以接受。
为什么要团队协作来适应领域？根据康威定律，团队组织架构和技术架构之间是相互映射的。如果领域的实现和团队的组织、协作结构不匹配，久而久之，整个领域就会朝着与这个团队组织方式更接近的方向发展，而它自然而然地就带来了在领域知识表现上的缺失。
不要照搬业务团队的划分
以电商为例，假设业务系统目前划分为：APP服务端、商品信息管理、物流管理、仓库管理、SKU开发平台。
但限界上下文不一定要按此进行划分，还是应如实还原领域本来的样子。比如仓库管理和商品信息管理之间共有一个“商品库存”的概念，SKU开发平台和商品信息管理平台之间也有一个共同的“SKU”概念
沿着连接最少的地方下刀
这一点比较抽象，实用性可能没那么强。想像所有的模块之间通过互相的函数调用相连，组成了一张关系网。互相之间关系越紧密的模块，调用线也越密集。 所以不难想像，如果我们真的可以画出这样的关系图，沿调用线最少的地方下刀进行切割，就一定能把整个领域切割成多个互相之间影响尽可能小的限界上下文。
尽管我们很难画出一个真正完备的关系网，但也可以大致梳理出各模块之间的亲疏关系。
只吸取DDD中的精华
我认为，DDD中最精华的概念就是：
- 使用统一语言进行讨论
- 强调了建立完整领域的重要性
因此，如果实现原汁原味的DDD有些困难，可以试着实现一个“精简版 ”，只吸取其中的核心思想。
团队讨论： 建立术语表，尽量使用统一语言，最起码在产研内部统一，并在与业务方沟通时将他们的话语转译成自己的领域语言后让业务方确认描述是否准确
领域：产研内部维护领域知识图，并用来进行服务拆分，但不在代码中实现完整的领域层。
架构设计：分层+六边形架构， 基本上分为接口-服务层-数据层。(不需要领域层)
服务拆分： 基于领域进行拆分
