DDD领域驱动设计

DDD 把模型分成四层。

分层设计.png

1. UI 层，负责界面展示。
2. 应用层（Application Layer），负责业务流程。
3. 领域层（Domain Layer），负责领域逻辑。
4. 基建层（Infrastructure Layer），负责提供基建。

分类的依据是：越往上，预期变动越频繁；越往下，预期变动越少

模型属于哪一层，有个粗略的判断方式：

如果一个实体（entity）和针对实体的增删改查，就属于领域层；
如果是一个场景，比如出现在UI菜单上的选项，就属于应用层。
前者是针对实体的操作，每一个实体都只有增删改查这样的操作，与之相反的是，要完整实现“购买商品”这个场景，也许需要检查库存，创建订单，创建交易等多个操作。

Repository 避免直接使用mapper，好处就是中间做了一层转接，可以用于对应一些逻辑处理，比如增加缓存等等，主要还是规避service直接使用mapper。

那直接改为service引用service不就一样？

答：service侧重复杂业务，Repository围绕crud，重心是数据操作

需要一个模式，能够隔离我们的软件（业务逻辑）和固件/硬件（DAO、DB），让我们的软件变得更加健壮，而这个就是Repository的核心价值。

最后，总结起来：
DDD 把业务分成 UI、应用、领域、基建四层，其核心是高度提纯、通用、少变化的领域层，是谓“领域驱动”；
领域层中包含领域模型，捕捉领域逻辑，暴露出接口用于操作领域模型，这些接口提供的操作可以确保领域是自洽的；
领域模型既是业务描述，又是代码实现的结构设计，二者的结合点在于公开出来的界面、接口。