dddjava例⼦_⼀个微服务+DDD（领域驱动设计）的代码结构
⽰例
前有幸拜读过诸多⼤神关于DDD的实现落地等⽂章，学习较多，受益匪浅，在此推荐 :
下⾯参考了DDD官⽅的结构，总结了前辈们的相关经验，再根据⾃⾝对微服务和DDD学习和理解，做了⼀个⽤SpringCloud搭建的最基本的结构例⼦。个⼈才疏学浅，如有雷同或是不当之处，望各位⼤佬见谅和帮忙指正。
⾸先引经据典 , 参考官⽅架构草图，DDD总体结构分为四层  :  Infrastructure(基础实施层)，Domain(领域层)，Application(应⽤
层)，Interfaces(表⽰层，也叫⽤户界⾯层或是接⼝层)，各个层⾯的作⽤下⾯介绍。
对于DDD的设计⽽⾔，最重要的是如何去划分领域，划分好边界。在代码设计上，之前有看到过⼤佬⽤模块(Modules)来进⾏上下⽂界定和划分。如图下 :
⽽对于微服务⽽⾔，就⾮常适合从业务上去划分以上的各个Modules，划分好各个业务板块。
微服务 + DDD，个⼈觉得应该是⾸先是从微服务的⾓度(如何划分微服务)考虑去划分⼤的业务模块，每⼀个微服务都应该是⼀个可以单独部署，各司其职的模块；
⽽在微服务实际开发中，结合DDD的思想去划分所有属于⾃⼰的领域。
常用微服务架构如图⽰例，对于我这个Project⽽⾔，是模块已经划分好的微服务应⽤，代码设计上就分为
Infrastructure，Domain，Application，Interfaces :
Infrastructure 层 :  基础实施层，向其他层提供通⽤的技术能⼒(⽐如⼯具类，第三⽅库类⽀持，常⽤基
本配置，数据访问底层实现)
Domain层 : 主要负责表达业务概念，业务状态信息和业务规则；是整个系统的核⼼层,⼏乎全部的业务逻辑会在该层实现。
Application层 :  相对于领域层，应⽤层是很薄的⼀层，应⽤层定义了软件要完成的任务，要尽量简单。
注 : 这⾥图⾥⾯所说的对内对外，对程序⽽⾔，事实上是从展现层调⽤应⽤层，应⽤层调⽤领域层，领域层或调⽤基础实施层。
Interfaces层 : 负责向⽤户显⽰信息和解释⽤户命令，请求应⽤层以获取⽤户所需要展现的数据(⽐如获取⾸页的商品数据)
⽆论我们代码结构如何规划，也并⾮⼀成不变，应该从实际出发，去思考划分结构的意义。此例⼦是对
于微服务+DDD反应到实际开发，代码的结构设计上的⼀种初步的思考与探索,⼀个样板⼯程，不应该成为我们对实际DDD思考与设计的限制，本例仅供参考。
感谢各位提出意见和⽀持。
(我个⼈对微服务的理解)Tips :
微服务架构设计，⼀个微服务应该就是⼀个可单独部署，可运⾏的应⽤，也就是微服务最⼩的运⾏单元。
微服务本⾝内部⾼度内聚，微服务与微服务之间低耦合。
⾸先对于应⽤划分上，就应该想清楚每个微服务的职责，每个微服务服务内部建⽴起⾃⼰的依赖，完成⾃⼰的职责和业务。
微服务与微服务之间交互通过HTTP或RPC接⼝调⽤，降低微服务之间代码实现和业务的耦合。
微服务的实现不应该受限某程序语⾔(或Java，或Go，或Python)，不应该受限于某框架(或SpringCloud，或Dubbo，或各种RPC框架等等)。
我的代码结构是对于⼀个微服务本⾝(即应⽤)划分的，领域是对于微服务内部本⾝⽽⾔的，即这个微服务涉及哪些领域。
⾸先从⼤的⽅向去划分每⼀个微服务，然后再从每⼀个微服务确定所包含的领域，领域的边界，等等。
⽐如划分了⼀个 认证授权服务，那么 领域可能有 ⽤户，权限；实体可能有⾓⾊，资源等等。领域⾏为有授权登录，⽤户退出，授权等等。
不要被框架和结构本⾝所限制！

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。