领域驱动设计实现之路

public interface CollectionOrientedUserRepository {    public void add(User user);    public User userById(String userId);    public List allUsers();    public void remove(User user); } 

　　对于面向持久化的资源库来说，在对聚合举行修改之后，我们需要显式地挪用sava()要领将其更新到资源库中。依然是User，此时的资源库如下：

public interface PersistenceOrientedUserRepository {     public void save(User user);     public User userById(String userId);     public List<User> allUsers();     public void remove(User user); }　　

　　在以上两种方式所实现的资源库中，虽然只是将add()要领改成了save()要领，可是在使用的时间却是纷歧样的。在使用面向荟萃资源库时，add()要领只是用来将新的聚合加入资源库；而在面向持久化的资源库中，save()要领不仅用于添加新的聚合，还用于显式地更新既有聚合。

　　领域事务（Domain Event）

　　在Eric的《领域驱动设计》中并没有提到领域事务，领域事务是最近几年才加入DDD生态系统的。

　　在传统的软件系统中，对数据一致性的处置惩罚都是通过事务完成的，其中包罗当地事务和全局事务。可是，DDD的一个主要原则即是一次事务只能更新一个聚合实例。然而，简直存在需要修改多个聚合的营业用例，那么此时我们应该怎么办呢？

　　另外，在最近盛行起来的微服务（Micro Service）的架构中，整个系统被分成了许多个轻量的程序模块，他们之间的数据一致性并不容易通过事务一致性完成，此时我们又该怎么办呢？

　　在DDD中，领域事务便可以用于处置惩罚上述问题，此时最终一致性取代了事务一致性，通过领域事务的方式到达各个组件之间的数据一致性。

　　领域事务的命名遵照英语中的“名词+动词已往分词”花样，即表现的是先前发生过的一件事情。好比，购置者提交商品订单之后公布OrderSubmitted事务，用户更改邮箱地址之后公布EmailAddressChanged事务。

　　需要注重的是，既然是领域事务，他们便应该从领域模子中公布。领域事务的最终吸收者可以是本限界上下文中的组件，也可以是另一个限界上下文。

　　领域事务的分外利益在于它可以记载发生在软件系统中所有的主要修改，这样可以很好地支持程序调试和商业智能化。另外，在CQRS架构的软件系统中，领域事务还用于写模子和读模子之间的数据同步。再进一步生长，事务驱动架构可以演酿成事务源（Event Sourcing），即对聚合的获取并不是通过加载数据库中的瞬时状态，而是通过重放发生在聚合生命周期中的所有领域事务完成。

　　总结

　　DDD存在战略设计和战术设计之分，过分地强调DDD的手艺性将使我们错过由战略设计带来的利益。因此，在实现DDD时，我们应该将战略设计也放在一个主要的位置加以看待。战略设计资助我们从一个宏观的角度视察和审阅软件系统，其中的限界上下文和上下文映射图资助我们准确地界分各个子域（系统）。DDD的战术设计则越发偏重于手艺实现，它向我们提供了一整套手艺工具集，包罗实体、值工具、领域服务和资源库等。虽然DDD的观点已经提出近10年了，可是在怎样实现DDD上，我们依然有很长的路要走。

　　作者简介

　　滕云，ThoughtWorks软件工程师，译有《实现领域驱动设计》等书。现在主要从事Java EE开发事情，感兴趣的手艺领域包罗Linux、DevOps和连续交付等。

 5/5   首页 上一页 3 4 5