实现领域驱动设计-模块

定义

模块也是一种DDD模型，跟实体、值对像、领域服务和领域事件一样，所以模块也应该是通用语言的表达，最重要就是体现其组织层次和命名，都是体现业务的，体现通用语言的

“在DDD中，模型中的模块表示了一个命名的容器，用于存放领域中内聚在一起的类”，这是书中这一章的第一句话，强调了是一个容器，存放的类要体现出高内聚的。并跟java的包或C#的命名空间类比，这就很好理解了，就是一个划分良好的层次目录结构，来存放内聚的类。

那模块跟限界上下文啥关系呢，一般来说限界上下文是包括模块的（从本章的理解上看，模块肯定是包含在一个限界上下文的，但我也不确定还有没例外），可从两个方面来理解：限界上下文是通用语言的边界，而模块是通用语言的组成部分，所以限界上下文也是模块的边界，即包含模块的；另外从类比来说，限界上下文一般是一个工程项目，而模块是“包package”，也是包含关系。

那这里的模块跟OSGi和Jigsaw的模块是什么关系，前面强调了这里的模块是通用语言的表达，是体现业务内聚的需要，OSGi和Jigsaw的模块是一种技术实现方案，体现在编译、打包、部署和发布上的需要，两者概念上是区分很大的。有联系吗，也有。按通用语言需要划分模块之后，即把类的代码划分到各个内聚的包中，之后可以借助技术实现上的模块概念，把这些不同的package，分别打包和发布，然后给其它代码工程引用和共享，比如对应到java中，可以把com.saasovation.agilepm.domain.model这个敏捷项目管理的领域模型（书中例子）的模块单独打包为一个jar，然后发布到maven仓库，然后代码工程可以引用和使用。但两者不是一一对应的，比如可以把com.saasovation.agilepm.domain.model和com.saasovation.agilepm.domain.service一起打包，作为Jigsaw的一个模块一起编译发布，也可以拆分，这是技术实现的选择了。

在模块的命名上，书中建议是com.公司域名.{限界上下文}.{子模块}，比如com.saasovation.agilepm.domai，但在实践上，特别是微服务思想，一般一个应用会划分很多限界上下文，即很多独立的微服务工程来组成，这种情况建议改为com.公司域名.{应用名}.{限界上下文}.{子模块}，然后不论是应用名或限界上下文这些模块名，都不建议使用商业产品名（名牌、品牌），因为这是易变的，有很多商业包装的，一般建议应用名起一个codename，如python，hadoop，而限界上下文肯定是体现通用语言的。

额外收获

P300 “当同层模块（Peer Module）间出现耦合时，我们应该杜绝循环依赖”，这其实也体现在分层架构中，同层的服务可以出现耦合，但不能循环依赖

问题

P308 “让我们首先看看用户界面层和其中的REST资源”一节，把相应的模块命名为：

com.saasovation.agilepm.resources

com.saasovation.agilepm.resources.view

即放在一个叫resources模块下，个人不建议这么放，因为跟maven建议的工程目录组织的resources目录有混淆的嫌疑，虽然两者是不相关的概念，但一样的名字还是容易混淆的。这里建议使用web或rest来命名改模块