如何更好的推广app,个人网站seo入门,qq钓鱼网站建设,易县做网站ddd架构浅析
背景介绍
什么是ddd架构#xff0c;是以ddd思想为参考#xff0c;做出一份符合ddd思想的框架。
随着技术的迭代升级#xff0c;越来越多的瓶颈暴露出来#xff0c;性能瓶颈#xff0c;系统复杂度瓶颈#xff0c;这些都逐一被迭代出的技术产物解决。最终的…ddd架构浅析
背景介绍
什么是ddd架构是以ddd思想为参考做出一份符合ddd思想的框架。
随着技术的迭代升级越来越多的瓶颈暴露出来性能瓶颈系统复杂度瓶颈这些都逐一被迭代出的技术产物解决。最终的一个产物微服务几乎完美解决了性能和系统复杂度的问题保证服务性能的前提下还简化了系统的复杂度降低开发难度让系统更加容易维护。
但是对于B端企业来说单单解决性能和系统复杂度问题还远远不够极度复杂的业务让系统难以维护动辄几百上千行的方法让开发人员头疼。每一个简单逻辑的背后都会存在多个业务方多个业务方的兼容使得逻辑变得复杂加上业务的变化频繁这一特点让系统的复杂度极速提高。
ddd很早就出现了由于过于复杂难以理解一直没有很好地最佳实践。ddd的核心思想就是为了解决B端企业的业务复杂度而生近些年ddd的突然爆火是因为有了最佳实践的落地比较出名的比如cola的应用分层框架。
ddd核心分模块思想
ddd的思想核心是通过领域建模、分层分包的模式来进行降低业务复杂度简化开发逻辑清晰业务流向。
通过cola的最佳实践可以把ddd进行落地并且由核心和拓展几个点来进行分析。
核心模块
核心分包为 适配器、领域、基建包
三个包都不相互依赖形成相互隔离的几个单独模块让每一个模块都只有很单一的能力这样就可以很好的把业务限制在领域中极好的来沉淀建立自己的核心业务能力。
适配器层
由于B端业务多样性且复杂所以需要单独的适配器来做将不同的业务来进行适配进入自己的核心且单一的能力中。
通过将单一能力增加多个适配器提高业务的适配能力。b端业务的多样性往往体现在数据及命名的多样性但核心的业务大体相同所以通过适配器可以极大降低因多样性带来的复杂度。
领域层
领域层的单独存在一方面是为了限制核心业务不会散落的到处都是另一方面是让开发更加聚焦在核心业务的开发上。通过一些策略及拓展模式就可以实现核心业务及其不同的特性。
B端企业级对外提供的能力一定是单一的只有这样才能逐渐沉淀自己在行业内的影响力如果什么都能支持反而会觉得什么都不强都不稳定。而且随着差异太大的业务会导致成本剧增。
单一的能力会逐渐去完善产品能力最终沉淀产出一个标准的行业产品。
在大能力不变的情况下不同的特性处理通过一些拓展点就可以快速实现接手。
基建层
在B端业务中三方依赖的侵入性变动也是对业务稳定性的一个侵蚀比如业务前期使用某种组件可以满足业务需求随着发展需要更换另一种组件这种组件变更给系统带来的稳定性影响是非常重要的因为组件的变更导致业务宕机是非常不合理的为了避免这种情况将三方组件完全隔离是非常必要的。
三方组件包括但不限于数据库、缓存、mq、三方接口、三方sdk、三方rpc等。
可以认为所有和外部交互的都应该限制在基建层以此来进行隔离保证系统的稳定性。
domain模块
domain是三个模块的轴承通过依赖倒置让三个模块相互隔离全都由domain拉着通过domain进行交互。
domain的必要性
从物理层面进行隔离让其他人不能使用其他模块的东西。
pom的变更应该提起cr人员的注意切实做好每一个pom变更避免在代码中引入坏味道。
引入之后通过规约来限制是很不合理的根据墨菲定律只要存在就一定会被人使用到。
非核心模块
client模块
如果系统有对外提供的能力比如rpc接口mq实体定义等。
这些内容是切面与系统存在的需要提供给外部引用应该单独出来避免把自己的核心内容给外部使用。
优势
避免由于外部使用不当导致自己内部的实体变更让交互不稳定。避免由于提供依赖太大导致对方系统的负担避免核心能力让对方引用增加安全风险
遵守规则
client包中不应有任何三方依赖只是一个简单接口及实体的定义不应有内部使用的包只需要提供外部所需的即可遵守最小可用原则统一出参封装所有对外提供的接口应统一封装方便框架层面做统一处理。
common模块
对应本应用而言在不同模块中都有使用到的工具分别定义是不合适的通过common包来抽象出共有能力来降低代码重复率。
ext模块
如果业务的多样性非常复杂对每一个特性的处理都需要大量的业务逻辑那么ext模块单独抽出就很有必要。多样性处理的太多和核心业务掺杂在一块随着业务的发展就会产生特性分支和主分支分不清的情况混用职责不清晰能力不单一。即使规约的再好根据墨菲定律这种问题一定会发生。
另外一些高阶的玩法ext模块外置核心能力很稳定拓展能力变动较大时ext模块会成为热插拔组件通过快速迭代更新来满足业务做到完全的系统热插拔不影响当前业务新的业务快速上线。
也为了避免不同特性分支相互影响通过这种做到完全隔离。
sop模块
核心业务稳定且领域模型较为完善业务进入后期阶段新的业务接入就不再依托于编码而且通过流程引擎来做编排让新的业务进入。
同一个业务能力有多种处理且都为核心能力此时就应该把这个作为一个sop把这些提出来一个sop模块单独处理原本核心的领域层做流程编排及其他前置业务处理。拓展点再次升级为某个sop的拓展能力。
一般情况下sop是ext的发展产物某个ext的特性分支业务发展很好逐渐成长为核心业务趋于稳定此时该特性分支就会成为核心能力分支。
最佳实践讲解
本节主要来解析每一个模块中应该放些什么每一层的依赖如何处理等。
分层模块
适配器模块
本层定位是系统入口所有的业务起点都应该在这里。
比如controller接口、rpc接口实现、mq消费者实现等。
本层依赖
内部依赖核心领域模块client模快、common模块。
三方依赖核心框架、rpc和mq等必要框架、基础组件。
禁止依赖业务模块、基建模块
特殊说明
本层的模型定义在本层内、或者取自client。
本层调用领域层之前需要做好模型转换将模型转换为领域层里面定义的模型然后再定义这层的转换器应该写在这层。
业务模块
本层定位为核心业务逻辑处理所有的业务处理都应在这里。
比如业务流程判断走向、业务逻辑判断、根据不同的数据做不同的处理、调用数据库接口、调用mq接口、和外部交互的逻辑等。
本层依赖核心领域模块、common模块。
三方依赖核心框架
禁止依赖适配器模块、基建模块、client模块、任何非必要三方依赖
特殊说明
本层不需要做任何类型转换进来就是自己所需要的模型。
本层不允许引入其他模块的模型这层的模型都应该非常稳定不能有三方注解比如rpc注解、fastjson注解、mybatis注解、mq注解等
基建模块
本层定位为防腐基础设施所有和外部的交互都应该在这里这里应该为单条线的末端。
比如从数据库中获取数据的最终实现从缓存中获取数据的最终实现发送mq的实际实现调用rpc接口的最终实现等。
本层依赖核心领域模块、common模块。
三方依赖核心框架、外部sdk、外部client模块、任何三方所需要的依赖。
禁止依赖适配器模块、client模块、业务模块
特殊说明
本层的模型可以用到领域模型或者三方交互模型。进来都是领域模型根据需求转换为对应的三方接口模型。
处理完如果有数据透出必须要使用类型转换器不可把本层模型透出也不能把三方接口模型定义到领域模块中。
领域模块
本层定位是不同模块的轴承所有的核心交互接口定义及数据模型定义都在这里这里联通各个模块。
比如核心业务处理的接口DomainService基础建设中的能力透出接口InnerService/Gateway)。
本层依赖common模块
三方依赖无
禁止依赖几乎不允许依赖任何内容
client模块
本层定位是本系统对外提供的能力点透出。
比如对外提供的rpc接口对外提供的mq模型等。
本层依赖无
三方依赖无
禁止依赖几乎不允许依赖任何内容
common模块
本层是不同模块之间通用的工具内容。
比如字符串处理工具各种util类各种通用处理能力。
本层依赖无
三方依赖非常稳定的三方工具包原则上需要自己重写一套几乎不能引用其他三方依赖。
start模块
应用的启动模块定义启动器及启动所必须得一些内容。
比如spring boot启动器启动配置项目中的一些配置。
本层依赖所有的模块
三方依赖基础框架依赖
ddd框架实践
一套最基础的增删改查实践
╔ adapter
║ ╟ java
║ ╟ ╟ RpcXXXServiceImpl.java
║ ╟ ╟ XXXController.java
║ ╟ ╟ XXXConsumer.java
║ ╟ resource
║ ╚ pom.xml
╟ biz
║ ╟ java
║ ╟ ╟ XXXDomainServiceImpl.java
║ ╚ pom.xml
╟ infra
║ ╟ java
║ ╟ ╟ XXXConverter.java
║ ╟ ╟ XXXClient.java
║ ╟ ╟ XXXInnerServiceImpl.java
║ ╟ ╟ XXXDO.java
║ ╟ resource
║ ╟ ╟ mapper
║ ╟ ╟ ╟ xxxMapper.xml
║ ╚ pom.xml
╟ domain
║ ╟ java
║ ╟ ╟ XXXDomainService.java
║ ╟ ╟ XXX.java
║ ╚ pom.xml
╟ client
║ ╟ java
║ ╟ ╟ RpcXXXService.java
║ ╟ ╟ XXXDTO.java
║ ╚ pom.xml
╟ common
║ ╟ java
║ ╟ ╟ XXXUtil.java
║ ╚ pom.xml
╟ start
║ ╟ java
║ ╟ ╟ Application.java
║ ╟ ╟ config
║ ╟ ╟ ╟ Config.java
║ ╟ resource
║ ╟ ╟ application.properties
║ ╟ ╟ META-INF
║ ╚ pom.xml
╚ pom.xml实际demo
TODO…
