DDD 领域驱动设计的大名大家应该都有所耳闻，但是实际项目完整落地 DDD 的很少。因为 DDD 概念繁杂，领域、子域、核心子域、通用子域、实体、值对象、领域服务、应用服务、领域事件、上下文等一大堆概念，直接把人绕晕，对应到实际业务模型时，横看成岭侧成峰，开发人员内部都难以达成一致。
因为 DDD 设计之初目标是作为复杂软件解决之道，但我们大部分应用并没有那么复杂，一个简单的应用使用这么一套复杂的概念，有点弄巧成拙。在微服务时代，设计原则就是根据领域划分上下文，单体应用复杂度大大降低，微服务需要一种精简的架构。
DDD 中的很多方法论，其中大部分大家在项目工程中都见过或者实践过。但 DDD 要求的前提过于理想，比如什么领域专家，通用语言等前提，在民工式敏捷开发，需求朝令夕改，996加速的大环境下，过于虚幻，难以落地。 所以我们没必要全盘照搬，应该因地制宜，去取精华去其糟粕，提炼出适合自己的应用架构。
Model
数据模型层。
定义数据结构，以及数据模型对应的 Repository 接口，但不包含具体实现。多个相关 Model 组成领域，此处对领域进行简化，不再纠结于子域、实体、值对象等细粒度概念。围绕 Model 定义 Repository 接口，不掺杂业务逻辑，供 Service 层调用，方便在 Service 层组成事务。
https://zhuanlan.zhihu.com/p/130945830?utm_id=0
按业务功能划分 按业务功能划分是最常用的方法之一。将整个系统按照业务功能划分成多个服务,每个服务负责一个或多个相关的业务功能。这种方法的优点是易于理解和维护,缺点是可能会导致服务之间的耦合度较高。
按数据划分 按数据划分是将整个系统按照数据划分成多个服务,每个服务负责一个或多个相关的数据。
3.技术角度：技术栈、重要程度、调用频率划分。
沉淀公共微服务，公共服务。
