领域驱动模型之ERP单品模块架构设计
模块划分
-
领域对象
用户根据持有的单据类型ID,去可用的单据流程池中查找单据流程池,拿到流程池之后,需要确定最终单据管理的操作是什么,相比原始业务对象,领域对象具有了行为
-
资源库
一些基础的数据库交互操作,数据库与Elasticsearch缓存同步等操作,相比传统的VO,由资源库屏蔽了敏感的直接对底层访问,相比以前vo,具有更高的内聚,低耦合
-
防腐层
在一个上下文中,有时需要对外部上下文进行访问,这时候用到防腐层,对外部上下文进行一次转义,类似dubbo框架中多处用到的transporter,adapter等,如:对资源库进行操作的同时,可能涉及到日志业务的读操作
-
领域服务
串联领域对象,资源库和防腐层等一系列领域内的对象行为,对其他的上下文提供结构,即操作的封装,dubbo框架在设计时也大量用到了这种设计方法,如为了兼容性问题,开发多种行为实现,利用SPI动态加载实现方法,达到封装整个实现过程的目的.
-
数据流转
-
上下文集成
通常集成上下文的手段有多种，常见的手段包括开放领域服务接口、开放HTTP服务以及消息发布-订阅机制。补充: 个人认为,事件驱动模型可以在这种业务下发挥很好的优势
分离领域
下图中领域服务是使用微服务技术剥离开来，独立部署，对外暴露的只能是服务接口，领域对外暴露的业务逻辑只能依托于领域服务。而在Vernon著作中，并未假定微服务架构风格，因此领域层暴露的除了领域服务外，还有聚合、实体和值对象等。此时的应用服务层是比较简单的，获取来自接口层的请求参数，调度多个领域服务以实现界面层功能。
随着业务发展，业务系统快速膨胀，我们的系统属于核心时：
应用服务虽然没有领域逻辑，但涉及到了对多个领域服务的编排。当业务规模庞大到一定程度，编排本身就富含了业务逻辑（除此之外，应用服务在稳定性、性能上所做的措施也希望统一起来，而非散落各处），那么此时应用服务对于外部来说是一个领域服务，整体看起来则是一个独立的限界上下文。
此时应用服务对内还属于应用服务，对外已是领域服务的概念，需要将其暴露为微服务。