领域驱动设计和实践

　　订单的实现类是gap.template.bookstore.model.Order，类中除了联系方式、邮寄地址等基本属性外，另有以下领域相关的行为：

init(...)，结算时挪用要领，凭据当前用户与购物车中的Items初始化订单，供用户修改。submit(...)，提交订单时挪用的要领，生存订单。cancel(...)，作废订单，把订单和相关item的状态设置为已作废，然后委托Dao举行持久化。dispose(...)，处置惩罚订单，首先更新订单项的状态，然后委托Dao持久化订单数据。reSubmit、setItemsStatus......

　　通过以上的形貌，我们可以看到，Order类基本上笼罩了现实天下中订单这个营业的所有行为和状态，是相对内聚的，这样的特征使其复用性大大增添，纵然未来开发新的模块，涉及到订单营业的，可以直接复用Order类。同时在后期维护中，若是我想相识订单的营业，直接读Order的代码就可以了。

　　从上图中我们还可以清晰的看到各个领域工具之间的关系。Order和Cart都聚合了Item，对应都是1...n，Item聚合了Book，对应关系1...1。Order划分与折扣、账户发生关联和挪用等等，整个网上书店的场景就这样形貌出来了。

　　另外，不要忘了BS，除了起到基础设施的作用外（事务治理和服务共享），它还要卖力调理和维护领域工具之间的关系。由于总会有些营业逻辑，既不属于这个领域工具，也不属于谁人，那这部门营业由谁来处置惩罚呢？由BS来处置惩罚。例如在治理员处置惩罚订单这个场景中，首先需要凭据订单信息获取账户，凭据账户信息确定折扣率，同时举行余额校验，若是校验通过，就会挪用订单工具的dispose要领处置惩罚订单，这个场景会涉及到Order、Account、Discount等工具，这样的营业逻辑，应该由BS实现。

　　IBookStoreDao是数据会见工具，可以被BS挪用，用来持久化工具，也可以被领域工具引用，用来持久化自身。

　　通过以上的形貌，我们可以看到，整个设计和实现是优雅、清晰的。营业逻辑没有聚集在BS中，而是疏散在BS和各个领域工具中，服务和工具都与现实天下的营业息息相关，无论是对领域专家、开发职员和后期维护职员，都能这种方式中获得自己需要的内容。

　　我们接纳领域驱动设计相对比力早，就我小我私家的磨练和实践而言，DDD对构建企业级应用开发平台和大型焦点营业系统的作用是很是显着的，无论是在产物的稳固性、扩展性、可维护性、生命周期等方面都有显著的提升。

　　可是，由于这样那样的缘故原由（庞大度、工期、开发职员能力限制等等），许多人会不自觉的抵制接纳DDD，有时间一个软件项目重写了两次，第二次依然不去做优秀的设计。事实上接纳了DDD的设计要领，我们的设计阶段已经变得很是轻量级和迅速了，开发职员只要能够把领域模子之间的关系画出来并形貌说明，并与需求职员告竣一致，那么做出来的工具基本上是靠谱的。

　　在手艺领域，只有自动的实验和提升，效果才是最显着的。许多人问过我，怎样最先学习和实践XXX，实在很简朴，现在就最先吧！

 4/4   首页 上一页 2 3 4