DDD 领域驱动决策规则树服务架构设计

在上一章节介绍了领域驱动设计的基本概念以及按照领域驱动设计的思想进行代码分层，但是仅仅只是从一个简单的分层结构上依然没法理解DDD以及如何去开发这样的微服务。另外往往按照这样分层后依然感觉和MVC也没有什么差别，也没有感受到带来什么非常大的好处。那么问题出在哪呢？我个人觉得DDD学起来更像是一套指导思想，不断的将学习者引入到领域触发的思维中去，而这恰恰也是最难学习的地方。时而感觉会了，而实际开发中又不对，本来已经拆解清晰了，但怎么又那么像MVC了。甚至怀疑自己，我在干嘛？,无论是DDD、MVC，他们更像是家里三居或者四局的格局，每一种格局方式都是为了更好的实现对应架构下的设计思想。但，不是说给你一个通用的架构模式，你就能开发出干净(高内聚)、整洁(低耦合)、漂亮(模块化)的代码。这就像是你家住三居、他家也住三居，但是你们屋子的舒适情况就一样吗？｛再有，你家里会把厕所安在厨房吗？但你的代码是否这么干过，不合理的摆放导致重构延期。｝,另外DDD之所以看着简单但又不那么好落地，个人认为很重要就是领域思想，DDD只是指导但是不能把互联网天下每一个业务行为开发都拿出来举例子给你看，每个领域需要设计。所以需要一些领域专家｛产品+架构+不是杠精的程序猿｝来讨论梳理，将业务形态设计出合理的架构&代码。,本案例通过一个商品下单规则的场景来进行演示DDD；,,bugstack虫洞栈 & 分层结构,通过领域驱动设计的思想，从领域知识中提取和划分为一个一个的子领域（核心子域，通用子域，支撑子域），并在子领域上建立模型。那么在技术实现上就需要去支撑这种建模，以使我们的代码模块独立、免污染、易于扩展。,在上面我们提到需要开发一个可扩展使用的规则树，那么如果只是单纯的一次性需求，最快的方式是if语句就搞定了。但是为了使这个领域服务具备良好的使用和扩展性，我们需要做些拆分，那么如下；,,bugstack虫洞栈 & 领域开发设计服务,domain中有两个领域服务；规则树信息领域、规则执行领域，通过合理的抽象化来实现高内聚、低耦合的模块化服务,1、实现领域层仓储定义 2、数据库操作为非业务属性的功能操作 3、在仓储实现层进行组合装配DAO&Redis&Cache等,1、包装应用接口对外提供api 2、外部传输对象采用DTO类，主要为了避免内部类被污染｛不断的迭代的需求会在类中增加很多字段｝ 3、目前依然是提供的Http服务，如果提供的rpc服务，将需要对外提供可引用jar,通过postman调用 | raw => json,查询规则树信息 测试接口：http://localhost:8080/api/tree/decisionRuleTree 请求参数：{“treeId”:10001},,微信公众号：bugstack虫洞栈 & 查询规则树信息,规则树行为信息决策 测试接口：http://localhost:8080/api/tree/decisionRuleTree 请求参数：{“treeId”:10001},,微信公众号：bugstack虫洞栈 & 规则树行为信息决策