SpringBoot+JPA实现DDD（⼀）
前⾯2篇, 已经说明了为什么要使⽤DDD，现在来看⼀个具体的例⼦：
明确需求
业务需求
假设我们要实现⼀个商品中⼼这个核⼼领域。要求如下：
商品包含⼀个或多个明细。⼀个明细也可以被包含在多个商品⾥。明细有三种：在线课程、实体书、线下服务。明细不可单独售卖，但可以单独编辑
商品和明细都有类⽬
商品的类⽬和明细的类⽬可以保持⼀致，也可以不保持⼀致jpa mybatis
明细在不同的商品中可以有不同的价格
商品的价格是各明细的价格的总和。商品的价格不可修改，可通过添加优惠券实现减价。
在线课程的有效期分两种：截⽌⽇期，下单后xx⽉。
商品有状态，必须是上架状态才可以售卖，上架后不可修改
商品要审核后才能上架，因为商品内可能有违规的图⽚、⽂字，所以必须要经过法务审核
构建模型
1.商品在其⽣命周期内是可修改的，且有唯⼀的标识，很明显是个实体。并且，商品是跟外界交互的⼊⼝，它是⼀个聚合根。
2.课程有唯⼀的标识，可被修改，虽然它被包含在商品内，但是它可以单独编辑。⼀个商品被下架了，但是这个课程在其它商品⾥仍然可以被售卖。它的⽣命周期是独⽴的，所以它也是⼀个聚合根。
3.实体书和线下服务同理，也是聚合根。
4.优惠券⽐较特殊。它有⾃⼰的⽣命周期。如果优惠活动很多，也很复杂，应该将优惠拆分成⼀个单独的⽀撑领域。这样优惠可以做的很复杂，⽐如弄⼀个规则引擎来配置各种优惠券。这⾥我只做⼀个实现DDD的demo，不搞那么复杂，暂时不考虑优惠。
5.审核也⽐较特殊，它应该是⼀个通⽤领域。这⾥不考虑审核。
实现模型
需要数据库设计吗？个⼈认为不需要了。还记得hibernate的ORM和⾃动建表的功能吗？曾经我们对hibernate弃如敝履，现在回过头来看，也许我们⽤错了。
我们总以为Hibernate⾃动⽣成ddl的功能很鸡肋，那是因为我们太习惯于先建表，后写代码了。我们⼀直以为数据库设计是基⽯，只有把数据库设计好了，才能可靠地实现业务。⼈家DDD根本不是这么玩的。先设计数据库，开发⼈员跟业务之间就被这个数据库的表结构给隔离开了。其关系是：业务 <--> 数据库 <--> 开发。
DDD的玩法是：开发 <--> 业务 <--> 仓储（数据库），看到区别了吗？这种玩法是直⾯业务。DDD好玩的地⽅就在于：真正的程序员敢于直⾯复杂的业务！
我知道⼤家嫌弃hibernate，很重要的⼀个原因是关联表查询的时候很难受。⼀提到这个⼤家都感同⾝受。现在为什么我改变主意了呢？因为实现DDD的时候可以采⽤CQRS（读写分离）架构。这样⼀来，在写数据的时候只需要少量简单的查询即可，复杂的查询放在读模型⾥，读模型不需要跟写模型保持⼀致，读的时候可以选择原⽣的SQL，Mybatis，或者NoSQL，再也不⽤担⼼配置复杂的⼀对多，多对多等问题了。
据我所知，.Net的⼩伙伴⽐较熟悉DDD，可能是.Net有⼀整套DDD的框架吧。有⼈说Java⽤了Spring框架，天⽣的只能⽤贫⾎结构。因为实体⾥没有save,update等⽅法，所以是贫⾎的。这种说法是有问
题的。原因我在这篇⽂章⾥已经说过了，这⾥不再赘述了。如果有不同看法，欢迎留⾔讨论。DDD最有争议的就是这个“贫⾎”和“充⾎”模型了吧。
我打算⽤Spring Boot + JPA写⼀个DDD的demo。Spring Data JPA 默认就是Hibernate实现的，本系列⽂章JPA就是指Spring Data JPA, 具体的ORM框架就是Hibernate。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。