DDD 实战（理论不说）

---

 背景

业务初期，我们的功能大都非常简单，普通的CRUD就能满足，此时系统是清晰的。随着迭代的不断演化，业务逻辑变得越来越复杂，我们的系统也越来越冗杂。模块彼此关联，谁都很难说清模块的具体功能意图是啥。修改一个功能时，往往光回溯该功能需要的修改点就需要很长时间，更别提修改带来的不可预知的影响面。典型的就是目前所在公司的一个底层系统（下单接口）。

产品需求

通用用户抢购系统。可以根据用户等级优先抢购，超出抢购的时间范围抢购失效，需要有地区限制，比如北京地区的。抢购的总量和物品由客服在后台配置。

设计

根据产品需求抽象出库存池与库存

---

领域对象 

（具有具体的行为） 不在是贫血对象了

StockPool 库存池 ---> 库存, 用户类型, 商品, 地区, 开始时间 ，结束时间 行为 ： 获取库存

  Stock 库存 -->  总量，剩余数量      行为：去库存（纠正库存数量）

聚合根 （Aggregate(聚合）

是一组相关对象的集合，作为一个整体被外界访问，聚合根（Aggregate Root）是这个聚合的根节点。）

库存池列表  根据实际场景StockContext  行为 : 获取库存池

资源库 

（领域对象需要资源存储）可以试关系数据库，也可以是非关系数据库

  库存StockMapper

  库存池 StockPoolMapper

  缓存 redis

领域服务 

StockService 将上述组件进行聚合， 高内聚，低耦合