领域对象的关联设计

请大家访问原文地址：http://yanyaner.com/

 

 

正如DDD这本书所说的，领域驱动设计是应对日益复杂的软件系统开发的有效途径，前面的文章中我也讲过，领域模型是一个系统更本质、更核心的东西，准确地 抓住了域模型，你就抓住了系统的“神”，也就能更加灵活地应对需求的变化。我见过很多初学者在学会了ooad和一些设计模式的知识后，恨不得把学到的所有 东西都应用到系统设计当中去，最终的结果就是系统非常的复杂，难于实现和维护。我们知道，真正设计得好的系统，应该是简单的，一目了然。在进行领域模型设 计时，我们的一个原则就是要将复杂的系统简单化，关系要由多对多、一对多双向、一对多单向、一对一，直至独立的对象。大道至简，切不可走入“分析瘫痪”的 歧途。

在这里，我只想结合一个项目实际中的一部分，谈谈一对多双向及一对多单向的设计，希望大家在实际项目中能做到举一反三。

本项目是一个风电场实时监控系统，系统中有这么两组一对多关系：一级菜单和二级菜单，风机与风机实时监控记录，根据我们对需求的理解，有人很快设计出下面的领域图：

 

从图中可以看到，一级菜单和二级菜单均为一对多双向关联，注意secondMeuns与fanRecords集合是多方在一方中的代码体现，那像这种设计有什么好处、有什么问题呢？我们可以从两个方面来考虑这个问题：

一， 建立对象之间的关联关系，好处是对象之间可以方便地实现导航，即：得到聚合根对象后，就可以得到与之相关联的对象；缺点是实例化聚合根对象时将实例化与之 相关的所有对象，如果这些相关对象的在业务中从来没有被用到，则会造成不必要的内存与性能开销（当然，现在的很多ORM框架都有lazy功能，性能倒不是 大的问题）。

那也就是说，我们可以根据业务来确定一对多的关联关系，如果业务中90%的情况是读取到聚合根对象，都一定需要访问它相关的对 象，则可以设计为双向关联，在一方中添加一个集合存储多方对象，否则，则可简化为单向关联，也就成了多对一了（注意：我们这时站在多方的立场来看，是多对 一）。

根据需求及业务，我们可以做出这样的决策：一级菜单和二级菜单的设计要做成一对多双向关联；风机与风机实时记录，可设计为一对多双向关联，也可以设计为单向，因为很多时候仅仅是查看一下风机的信息，并不去关注该风机的实时记录，但有的时候也要查看。

二、综合业务与界面呈现来考虑。

根据需求来看，一个一级菜单中的二级菜单数据不会太多，即时全部加载出来，也不存在性能问题，从界面呈现来看，一级菜单中的二级菜单会一般情况下都会全部显示出来，因此，一级菜单和二级菜单两者设计为一对多双向关联关系，不存在任何问题。

再 来看风机和风机实时记录，根据需求，一个风机每10秒钟就会产生一条实时记录（每半年清理一次），实时记录的数据量将非常庞大，如果在风机这边设计一个实 时记录的集合，我敢保证你永远都不会直接去取这个集合中的数据（不信你调用fan.getFanRecordes()试一下哈），从界面上来看，一般都是 通过分页来查看风机实时记录的，因此，在Fan中包含FanRecordes集合，没有实际意义，也就是说，Fan与FanRecord设计为单向关系， 把前面的一对多双向关联改为现在的FanRecord与Fan的多对一关系（图我就不再去画了）。

也许你有疑问，在一方去掉多方的关联，要是业务实现时又要得到一方所关联的对象怎么办呢？答案是，添加一个相应的业务方法。

总的来说，领域对象之间关系在设计时，应根据需求、业务及界面实现等几个方面综合考虑，尽量将问题简化，当然，初学者喜欢将所学的全部应用到设计中，这也很正常的，我相信每个设计师经历过，大家都是这么过来的。