先以类图的方式来呈现概念之间的关系：
模块划分中涉及的概念
如上图，一个产品（或者项目）将会被拆分为多个模块（如果使用IDEA集成开发环境的话，可以产品和模块与IDEA中的project和module对应）。这里的模块是一个抽象的概念，主要分三类：
一类是业务模块。主要用于组织我们的业务代码，在整个产品（或者项目）生命周期内会因为业务需求持续迭代；
另一类是适配器模块。适配器模块在业务模块与技术中间件之间起到承上启下的作用。与业务模块不同，适配器模块会因为产品（或者项目）对质量需求（业界更多以非功能性需求叫法）更替掉技术中间件而更替。
最后一类暂且称之为启动模块。该模块主要存放一些接口实现类，这些实现类的作用其实跟适配器模块的作用一样，都起到防腐作用。这些接口来自于业务模块和适配器模块，此外，因接口的实现往往与选择部署方式相关，故称之为启动模块。
业务模块命名业务模块统一以domain-context-{contextname}形式命名。其中contextname就是DDD里的限界上下文名称。
例如：
domain-context-order表示订单限界上下文domain-context-customer表示客户限界上下文domain-context-alert表示告警限界上下文……
适配器模块命名适配器模块则以adapter-{rolename}-{technicalcomponentname}-[contextname]形式命名。其中adapter为固定名称（所有适配器模块都以adapter开头，同时也意味着该模块是可被替换的），rolename和technicalcomponentname为必提供项，contextname为可选提供项。
其中rolename表示角色名称，表示该technicalcomponentname技术中间件在此产品（或者项目）中充当的角色。
例如：
adapter-mqtt-activemq-iot表示activemq在iot限界上下文充当MQTT代理的角色adapter-mqtt-azureiothub-iot表示azureiothub在iot限界上下文充当MQTT代理的角色adapter-mq-activemq表示activemq在整个产品（或者项目）中充当MQ（消息队列）的角色。当然，此处如果考虑到以后每个限界上下文可能会独立演进（例如使用不同的mq技术组件），也可以将其拆分，补充上其依赖的限界上下文名称（此处先不做过度设计）adapter-persistence-mongodb-customer表示客户限界上下文使用MongoDB来持久化数据，即MongoDB在customer限界上下文充当持久化角色通过以上的模块命名，我们可以找到一个角色与技术中间件之间的关系。同一个技术中间件可以充当多个角色，一个角色也可以由多个技术中间件来扮演（可以同时生效）。
启动模块命名以bootstrap-{deploymenttype}形式命名。
举例说明，当业务模块需要当前登录用户的信息时，只需在业务模块里声明一个接口，然后交由启动模块去实现。对于单体应用来说，该接口的实现从会话中获取即；而对于微服务应用，则需要通过协议上下文中去获取，例如HTTP的HEAD，Dubbo的RpcContext等等。
以上是对DDD项目模块划分的一些想法，现记录下来，方便回顾。
