DDD架构图谱
2023-04-13 13:02:40 1 举报AI智能生成
DDD上下文、问题域、解决空间、项目结构、实体、聚合根
作者其他创作
大纲/内容
表示两个或多个界限上下文之间的映射关系，表达了不同的上下文之间是如何通过集成互相关联，指明哪些地方需要跟其它团队进行交流
U（up）表示上游，D（down）表示下游，ACL表示隔离防腐层
典型的映射图
上游：接收来自下游的服务调用，表明数据的流向，一般是从上游游向下游，会对依赖过下游服务均产生影响。所以上游一般是基础配置、通用上下文等
下游：向上游发起服务调用，依赖于上游服务。下游服务一般都可能是直接面向用户访问的，或者说离用户调用越近，如库内服务、任务服务等
上游不可直接调用下游服务，反之可以
下游调用上游服务时，需要引入ACL，可实现接口分离原则和内容翻译成本地上下文的领域对象（一般是值对象实例）
理解微服务中的上下游关系
上下文映射图
分支主题
核心思想：分层。重要原则：每层只能与下层结构发生耦合。对于严格分层架构，每层只能与其直接下方结构发生耦合；而对于松散型分层架构，允许上方任意层与下方任意层发生耦合
用户接口层负责接收和返回外部系统或用户的请求，进行用户输入验证（注意不是领域模型的验证）。不应该包含领域或业务逻辑
应用层用于控制持久化事务和安全认证，或向其它系统发送消息通知。不处理任何业务逻辑，但直接面向领域模型。表达的是用户故事和用例。一般来说是接收到用户界面的参数，通过资源库获得聚合实例，然后执行操作
领域层是核心，采用依赖倒置原则，使得领域层和基础设施层都依赖领域模型提供的接口。间接性的访问资源库和基础设施层提供的实现类。
DDD架构分层职责
分层架构一旦使用依赖倒置、依赖注入的方式，便不属于分层架构，自然就拥有了端口与适配器风格。各个组件的交互完全通过接口完成，而不是具体细节。无论是高层还是底层，都依赖于抽象（因抽象接口都定义在了领域层，看起来领域层已经成为了中心，层次架构已经是内外结构）
在六边形架构中，每条边要么代表客户输入交互的不同端口，通过不同类型的适配器进行适配完成格式协议转换等，从而实现程序内部可理解的输入类型；要么代表通过不同的适配器输出存储实例、向外界发送时间消息等输出类型
六边形架构中的内部六边形代表了应用程序，是一个应用程序的边界。应当根据应用程序的功能需求提供给外部适配器使用，要求使用领域模型来处理请求，并包含业务实现功能。这里我们可以看出，外部适配器可能存在无数个，但应用程序的个数是确定的且是根据业务需求决定的，提倡业务逻辑为关注点（六边形的核心），其余都是可替换的。外部都是可替换的
六边形架构（端口与适配器）
架构风格等同于架构设计模式，将不同架构实现所共有的元素抽象出来，使其不依赖于技术细节中。REST（表现层状态转化）定义了信息资源（可以有多种形式，一般使用URI指向）对外的呈现形式，实现了客户端和服务端通过手段（GET、POST、PUT、DELETE）进行交互，实现“状态转化”的过程。
在六边形架构中，适配器层是以组件性质提供服务，SOA和REST扮演了适配器层的角色。
REST风格架构
CQRS意为命令和查询职责分离，在高并发、分布式、大数据场景下，运用读写分离技术，将读操作和写操作的模型分开并提供不同的通道供用户使用
为什么需要CQRS：传统的读写模型混在一起，适配器层通过与操作无关的信息被数据传输对象（DTO）经过领域模型到达DB，导致领域模型的的业务流程被弱化。同时，为适应读写同时操作，DTO会设计得臃肿，并需要多次转换，增加了复杂度，这种结构在读操作为主的高并发系统中缺点尤为突出
系统中的业务都是通过事件驱动完成，系统事件体现模型状态，通过一定的事件序列表示，不一定会保存到数据库中。任何领域对象都是事件的叠加和还原确认
Event Strore：事件序列存储
视图：最新事件保存的表，保存完整的对象信息供读模型使用
组成组件
为保证读写分离后读模型时效性和最终一致性，需要引入事件溯源（Event Source）的概念
事件溯源与CQRS：事件溯源的Event Store得到视图给读模型。发生状态改变的写模型形成的Event，通过读取的“旧状态”与视图结果进行叠加，即可得到新的状态结果达到最终一致性（https://zhuanlan.zhihu.com/p/477644223）
CQRS
架构
领域专家并不是一个职位，而是可以是精通业务的任何人。他只需更多的了解业务的背景知识
领域模型是某个关于特定业务领域的软件模型。通常通过对象模型来实现，对象模型包含了数据和行为，并表达了准确的业务含义
将领域专家和开发人员聚集到一起，这样开发出的软件能够反映出领域专家的思维模型。需要统一语言的支持。
实现战略设计，可清楚的划分不同的系统额业务关注点，指引实现面向服务的架构或业务驱动架构
实现战术设计建模，满足了软件真正的技术需求。战术设计工具使得开发人员能够按照领域专家的思维模型开发可测试的软件
DDD关注的三个方面
DDD的两大支柱：通用语言和界限上下文
业务价值：1、得到了一个非常有用的领域模型；2、业务得到了更加准确的定义和理解；3、更加清晰的边界；4、更好的企业架构；5、敏捷、迭代式和持续建模
挑战：1、需要为创建通用语言腾出时间和精力，思考业务领域和概念术语并沟通改进（核心域）；2、持续性的引入领域专家；3、改变原有的思考问题的方式，仔细思考领域对象模型的行为
DDD概述
问题空间：思考的是业务的挑战，是领域的一部分，对问题空间的开发将产生新的子域。是核心域和其它子域的组合，各自关注当前的业务问题
领域：一个企业组织的业务范围和所进行的活动，正常来说，它表示整个业务系统，被划分为若干个子域，领域模型在界限上下文中完成开发
核心子域：是业务领域的一部分，是业务成功的主要促成因素。具有最高的优先级、最资深的领域专家、最优秀的开发团队。是最需要关注的域
支撑子域：对应业务的某些重要方面，但不是核心，仅作为专注业务的某个方面
通用子域：被用于整个业务系统，提供基础的支撑通用功能，甚至无需自己进行开发
子域
解决方案空间：思考的是如何实现软件已解决业务挑战。是一组可定的软件模型。是一个特定的，通过软件的方式来实现的解决方案
界限上下文：是一个边界，领域模型就存在这个边界之内。当模型处于这个边界上时，含义就是确定的了。是一个语义上的边界。跟通用语言切不可分
划分原则：一般一个上下文即可对应一个子域。一个界限上下文可以就是一个微服务或一个模块。当同一个业务名词在不同的阶段具有不同的含义，那么歧义的地方就是边界所在。将问题空间和解决方案空间融合到一起
隔离内核：可重用的模型分离到单独的界限上下文中，并在不同的界限上下文中进行合适的集成。应用服务负责集成协作
域和界限上下文
问题空间
解空间
DDD架构图谱
0 条评论
下一页
