一个微服务+DDD(领域驱动设计)的代码结构示例

本人此博文见识短浅,样例做法并不足取,请诸位移步。 前有幸拜读过诸多大神关于DDD的实现落地等文章,学习较多,受益匪浅,在此推荐 : https: www

本人此博文见识短浅,样例做法并不足取,请诸位移步。

前有幸拜读过诸多大神关于DDD的实现落地等文章,学习较多,受益匪浅,在此推荐 : 

https://www.cnblogs.com/hafiz/p/9388334.html
https://www.cnblogs.com/netfocus/archive/2011/10/10/2204949.html
https://blog.csdn.net/bluishglc/article/details/6681253

下面参考了DDD官方的结构,总结了前辈们的相关经验,再根据自身对微服务和DDD学习和理解,做了一个用SpringBoot搭建的最基本的结构例子。个人才疏学浅,如有雷同或是不当之处,望各位大佬见谅和帮忙指正。

首先引经据典 , 参考官方架构草图,DDD总体结构分为四层  :  Infrastructure(基础实施层),Domain(领域层),Application(应用层),Interfaces(表示层,也叫用户界面层或是接口层),各个层面的作用下面介绍。

                        

                    

对于DDD的设计而言,最重要的是如何去划分领域,划分好边界。在代码设计上,之前有看到过大佬用模块(Modules)来进行上下文界定和划分。如图下 : 

 

而对于微服务而言,就非常适合从业务上去划分以上的各个Modules,划分好各个业务板块。

微服务 + DDD,个人觉得应该是首先是从微服务的角度(如何划分微服务)考虑去划分大的业务模块,每一个微服务都应该是一个可以单独部署,各司其职的模块;

而在微服务实际开发中,结合DDD的思想去划分所有属于自己的领域。

如图示例,对于我这个Project而言,是模块已经划分好的微服务应用,代码设计上就分为  Infrastructure,Domain,Application,Interfaces : 

            

 

Infrastructure 层 :  基础实施层,向其他层提供通用的技术能力(比如工具类,第三方库类支持,常用基本配置,数据访问底层实现)

 

       

 

Domain层 : 主要负责表达业务概念,业务状态信息和业务规则;是整个系统的核心层,几乎全部的业务逻辑会在该层实现。

 

       

 

Application层 :  相对于领域层,应用层是很薄的一层,应用层定义了软件要完成的任务,要尽量简单。

  注 : 这里图里面所说的对内对外,对程序而言,事实上是从展现层调用应用层,应用层调用领域层,领域层或调用基础实施层。

 

    

 

 Interfaces层 : 负责向用户显示信息和解释用户命令,请求应用层以获取用户所需要展现的数据(比如获取首页的商品数据)

 

   

 

以上,就是个人 对 微服务+DDD的代码结构示例,完整代码详见 https://github.com/EalenXie/spring-microservice-ddd

无论我们代码结构如何规划,也并非一成不变,应该从实际出发,去思考划分结构的意义。此例子是对于微服务+DDD反应到实际开发,代码的结构设计上的一种初步的思考与探索,一个样板工程,不应该成为我们对实际DDD思考与设计的限制,本例仅供参考。

感谢各位提出意见和支持。

 

  (我个人对微服务的理解)Tips : 

  微服务架构设计,一个微服务应该就是一个可单独部署,可运行的应用,也就是微服务最小的运行单元。
  微服务本身内部高度内聚,微服务与微服务之间低耦合。
  首先对于应用划分上,就应该想清楚每个微服务的职责,每个微服务服务内部建立起自己的依赖,完成自己的职责和业务。
  微服务与微服务之间交互通过HTTP或RPC接口调用,降低微服务之间代码实现和业务的耦合。
  微服务的实现不应该受限某程序语言(或Java,或Go,或Python),不应该受限于某框架(或SpringCloud,或Dubbo,或各种RPC框架等等)。
  我的代码结构是对于一个微服务本身(即应用)划分的,领域是对于微服务内部本身而言的,即这个微服务涉及哪些领域。
  首先从大的方向去划分每一个微服务,然后再从每一个微服务确定所包含的领域,领域的边界,等等。
  比如划分了一个 认证授权服务,那么 领域可能有 用户,权限;实体可能有角色,资源等等。领域行为有授权登录,用户退出,授权等等。
  不要被框架和结构本身所限制!