![](https://img-blog.csdnimg.cn/20201014180756928.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
DDD
csdn_9527666
这个作者很懒,什么都没留下…
展开
-
控制软件复杂度的原则
导致软件系统变得复杂的成因是规模、结构与变化三要素控制复杂度的原则:就需要对 规模、结构与变化 逐个击破规模保证系统的小规模,分而治之,小即是美在应对新需求时,不会直接去修改一个复杂的旧系统,而是通过添加新特性,然后对这些特性进行组合。要满足小程序之间的自由组合,就需要满足第二条原则,即每个程序的输入和输出都是统一的,因而形成一个统一接口(Uniform...原创 2020-05-04 20:01:46 · 732 阅读 · 0 评论 -
代码模型的架构决策
代码模型 体现了 代码模块的 结构层次架构视图中 代码模型 作为其中一个视图 展现模块的 划分 定义运行时实体 与 执行视图建立联系代码模型的设计可以分为两个层次,具体如下。 系统层次:设计整个软件系统的代码模型。 限界上下文层次:设计限界上下文内部的代码模型。 针对整个软件系统,我们可以将这些限界上下文视为一个黑盒子。仅需关心限界上下文暴露的接口以及它...原创 2020-04-02 23:58:22 · 281 阅读 · 0 评论 -
代码模型
在 理解了 限界上下文 以及 分层架构 的本质基础上 需要确认系统的代码模型每个团队 无需 都遵守一套 代码模型在同一个项目中 必须 1遵守 同一个代码模型 并需要 2 知道 如此划分代码的 意义 与价值代码模型设计之前已经分析过1 层与层之间的协作2 跨限界上下文之间的协作考虑限界上下文的代码模型时,需要考虑纵向架构除前端之外的所有层次或模块...原创 2020-04-02 23:57:51 · 1116 阅读 · 0 评论 -
限界上下文与架构
限界上下文对 领域驱动架构 有直接到影响识别限界上下文 与 上下文映射 都是重要过程限界上下文是 逻辑架构 以及 物理架构的 参考模型上下文映射体现了系统架构的通信模型限界上下文不仅仅作用于领域层 以及 应用层是架构设计 而非仅仅领域设计的关键因素限界上下文 是一个 垂直的 架构边界针对后端架构层次的垂直拆分例如:订单上下文的内部就包含...原创 2020-04-02 23:57:13 · 550 阅读 · 0 评论 -
DDD各层次职责与协作关系
架构演进得到了 符合DDD思想的分层架构 是一种静态逻辑划分实现业务用例时,各层之间是怎么协作的?辨别动态协作关系的方法:从职责的角度入手,清楚地理解分层架构中每个层次的职责案例:电商系统的下订单场景在买家提交订单时,除了与订单直接有关的业务之外,还需要执行以下操作: 订单数据的持久化:OrderRepository 提供插入订单功能。它属于...原创 2020-04-02 23:56:37 · 1674 阅读 · 0 评论 -
DDD的演进
演进领域驱动架构的着手点:1 避免领域模型出现贫血模型2 保证领域模型的纯粹性避免贫血的领域模型经典三层架构中1 领域逻辑 在 业务逻辑层的service对象中2 反映了领域概念的 领域对象 被定义为Java Bean 此 Java Bean未包含任何领域逻辑 被放在 数据访问层3 DAO 对象仅负责与数据库的交互,并实现领域对象到数据表的 CRUD(增删...原创 2020-04-02 23:56:05 · 202 阅读 · 0 评论 -
分层架构的演化
架构设计最高原则: 高内聚、松耦合 的软件系统架构整洁架构设计出干净的应用层 以及 领域层 仅仅关注业务逻辑 不包含任何 具体技术实现优点:完成领域与技术之间的完全隔离领域模型就是业务逻辑的模型,它应该是完全纯粹所有领域模型对象都应该是 POJO(Plain Ordinary Java Object)。POJO 指的是一个普通的 Java 对...原创 2020-04-02 23:55:27 · 470 阅读 · 0 评论 -
分层架构基础
为什么要将业务与基础设施分开?答:引起它们变化的原因不同 单一职能原则的体现经典分层架构最为经典的就是三层架构以及领域驱动设计提出的四层架构。经典三层架构:用户界面层(User Interface Layer)、业务逻辑层(Business Logic Layer)与数据访问层(Data Access Layer) 如下图所示:流行原因:系统复杂...原创 2020-04-02 23:54:53 · 428 阅读 · 0 评论 -
辨别限界上下文的协作关系
1 是否存在关系2 是何种关系3 基于变化导致的影响来确定是否需要引入防腐层、开放主机服务等模式4 发现协作关系有不合理之处,则需要反思之前我们识别出来的限界上下文是否合理。限界上下文通信边界对协作的影响怎么做:如何确定限界上下文之间的关系?1 全面考虑参与到两个限界上下文协作的业务场景2 在场景中识别二者之间产生依赖的原因3 确定依赖的方向,进而确定集成点...原创 2020-04-02 23:54:16 · 369 阅读 · 0 评论 -
上下文映射的通信集成模式
防腐层与开放主机服务目的:降低限界上下文之间的耦合关系防腐层:(下游限界上下文对 上游限界上下文变化的隔离)是什么:设计思想“间接”的一种体现方法:通过引入一个间接的层,就可以目的:有效隔离限界上下文之间的耦合设计模式:间接的防腐层还可以扮演“适配器”的角色、“调停者”的角色、“外观”的角色防腐层往往属于下游限界上下文,用以目的:隔绝上游限界上下文可能发...原创 2020-04-02 23:53:45 · 270 阅读 · 0 评论 -
上下文映射的团队协作模式
原则: 各司其职 权责分明从组织角度看:预防一个团队 权利膨胀 团队势力扩大到整个组织从团队角度看:避免自己权利被压缩,导致话语权减小如何平衡?满足合理分配职责的前提下,谨慎地确保每个限界上下文的粒度。领域驱动设计根据团队协作的方式与紧密程度,定义了五种团队协作模式:合作关系:合作得越多,就意味着依赖越多:二者可能存在强耦合关系,甚至是糟糕的双向依赖...原创 2020-04-02 23:53:06 · 355 阅读 · 0 评论 -
上下文映射
降低业务复杂度的有效手段:分治法软件设计难题: 如何分 限界上下文如何确定限界上下文之间怎么合: 上下文映射分是合的基础 隔离是复用的前提上下文映射:“合”就是要尽可能地降低 不同上下文 之间的耦合。意义:解决限界上下文之间的协作问题上下文映射图:U 代表上游,D 代表下游上游产生的变化会影响到下游 下游依赖于...原创 2020-04-01 23:56:55 · 558 阅读 · 0 评论 -
从应用边界识别限界上下文
质量属性:关乎质量属性的问题 视为在将来可能会发生,其实就是“风险(Risk)”。架构是重要的东西,是不容易改变的决策。未曾预测到系统存在的风险,不幸它又发生了,带给系统架构的改变可能是灾难性的为什么说限界上下文是领域驱动设计中最重要的元素?:原因:限界上下文的边界,就可以将这种风险带来的影响控制在一个极小的范围更改了技术选型,选择基于 Elastic...原创 2020-04-01 23:56:21 · 344 阅读 · 0 评论 -
从工作边界识别限界上下文
限界上下文划分业务边界: 从业务相关性(内聚)判断业务的归属基于团队合作划分工作边界: 帮助我们确定限界上下文合理的工作粒度按照团队合作的角度划分限界上下文,其实是一个动态的过程、演进的过程。从团队合作层面看待限界上下文,就从技术范畴上升到了管理范畴一个高效的团队需要满足两点要求:1 共同的目标2 团队的边界设计团队组织时确定工作边界的原则...原创 2020-04-01 23:55:45 · 284 阅读 · 0 评论 -
识别限界上下文
从业务边界识别限界上下文领域驱动设计围绕着“领域”来开展软件设计。:1 明确了系统的问题域和业务期望2 梳理出主要的业务流程,这些业务流程体现了各种参与者在这个过程中通过业务活动共同协作,最终完成具有业务价值的领域功能。参与角色(Who)、业务活动(What)和业务价值(Why)3 抽象出不同的业务场景,这些业务场景又由多个业务活动组成,我们可以利用前面提到的领域场景分析方法(用例...原创 2020-04-01 23:55:14 · 417 阅读 · 0 评论 -
限界上下文的控制力
限界上下文目的:不在于如何划分边界 而在于如何控制边界对于统一语言:限界上下文是语言的边界对于领域模型:限界上下文是模型的边界语言的边界以及模型的边界可以 界定问题域对于系统架构:限界上下文确定了应用边界和技术边界限界上下文 分离了业务边界目的:约束不同上下文的领域模型例如 电商中的产品:1 采购上下文:关注产品...原创 2020-04-01 23:54:41 · 379 阅读 · 0 评论 -
限界上下文
限界上下文的含义:用一个清晰可见的边界(Bounded)将这个上下文(Context)勾勒出来Context 表现了业务流程的场景片段上下文(Context)其实是动态的业务流程被边界(Bounded)静态切分的产物。上下文(Context)是业务目标,限界(Bounded)则是保护和隔离上下文的边界,避免业务目标的不单一而带来的混乱与概念的不一致。限界上下...原创 2020-04-01 23:54:06 · 2155 阅读 · 0 评论 -
统一语言
统一语言定义:需求分析的过程(系统目标、范围、具体功能达成一致的过程)中提炼领域知识的产出物意义:在统一语言的前提下可以寻找正确的领域概念,为建立领域模型提供重要参考。 消除领域专家与团队、以及团队成员之间沟通的分歧与误解统一语言的体现:1 统一的领域术语2 领域行为描述统一的领域术语:在两个不同的语言世界中进行正确翻译的过程(如 开发人员与领域专家之间,他...原创 2020-04-01 23:53:34 · 685 阅读 · 0 评论 -
领域场景分析提炼领域知识
组成场景的要素:6W模型:Who:用户、What:业务功能、Why: 业务价值、Where:domain、When:应用层对domain层调用的时序、How:业务实现领域场景分析前提:识别参与该场景的用户角色(WHO)业务功能(What):分析该用户 特征属性 辨别其在在整个场景中参与的活动(如订单系统 用户只参与了下单)...原创 2020-04-01 23:53:00 · 589 阅读 · 0 评论 -
DDD对软件复杂度的应对
表象:规模与结构 导致 理解力障碍变化 导致 预测能力问题根因:需求DDD关注的焦点 在于 领域 以及 领域逻辑原因: 软件系统的本质: 给客户提供具有业务价值的领域功能需求分为业务需求:业务复杂度技术需求:技术复杂度面对一个相对复杂的软件系统时,面临的问题: 问题域过于庞大而复杂,使得从问题域中寻求解决方案的挑战增加,该...原创 2020-04-01 23:52:12 · 351 阅读 · 0 评论 -
控制软件复杂度的原则
导致软件系统变得复杂的成因是规模、结构与变化三要素控制复杂度的原则:就需要对 规模、结构与变化 逐个击破规模保证系统的小规模,分而治之,小即是美在应对新需求时,不会直接去修改一个复杂的旧系统,而是通过添加新特性,然后对这些特性进行组合。要满足小程序之间的自由组合,就需要满足第二条原则,即每个程序的输入和输出都是统一的,因而形成一个统一接口(Uniform...原创 2020-04-01 23:51:34 · 463 阅读 · 0 评论 -
DDD与软件复杂度
DDD解决的是 软件开发的复杂度问题 只有应用在大型项目上才能产生最大的收益DDD 可以应对以下问题: 没有对行为的重用,也没有对业务问题的抽象,每当操作用到业务规则时,都要重复这些业务规则。 快速的原型建立和迭代很快会达到其极限,因为抽象的缺乏限制了重构的选择。 复杂的功能很快会让你无所适从,所以程序的扩展只能是增加简单的应用模块,没有很好的办法来实现更丰富的...原创 2020-03-31 13:43:05 · 375 阅读 · 0 评论 -
DDD基础
是什么:领域驱动设计是一种方法论:是针对软件开发领域提出的一套系统与理论分析方法 是一种思维方式,也是一组优先任务目的:降低或隐藏整个系统的业务复杂性,并使得系统具有更好的扩展性,应对纷繁多变的现实业务问题。 加速那些必须处理复杂领域的软件项目的开发方法:1 将要解决的业务概念和业务规则转换为软件系统中的类型以及类型的属性与行为2 合理运用面向对象的封装、继承和多态等设计要素...原创 2020-03-31 13:42:35 · 354 阅读 · 0 评论