关于运维:DDD领域设计概念梳理

5次阅读

共计 2626 个字符,预计需要花费 7 分钟才能阅读完成。

工具与资源核心
帮忙开发者更加高效的工作,提供围绕开发者全生命周期的工具与资源
https://developer.aliyun.com/…

概念及阐明了解

畛域

畛域与具体开发技术无关。就是你的软件系统要解决的理论问题相干的所有货色的汇合。
按问题域了解:每个限界上下文专一于解决某个特定的子域的问题,限界上下文能够了解为问题空间 (Problem Space),随着设计和含意的清晰化,限界上下文会迅速的转换为解决方案空间(Solution Space)

十分构造清晰的一张图

畛域的整体概念图

限界上下文

限界上下文(Bounded context)是一个显式边界(边界:通常是一个子系统或者一个特定团队的工作),畛域模型存在于边界之内。建设模型过程中造成了通用语言,通用语言在特定上下文中才有明确的意义。
限界高低文书语义和语境上的边界,用于表白其边界内的软件模型。在限界上下文内的软件模型有着特定的含意并且在解决独特的事务。
按团队工作了解:一个团队应该在一个限界上下文中工作,依据组织大小可能对应一个大部门也可能对应一个小团队,如果是大部门,则小团队围绕着子域 / 聚合工作。

上下文映射图

限界上下文之间会相互集成,这种集成关系称为上下文映射
上下文映射图不是一种企业架构,也不是零碎拓扑图,他是梳理限界上下文的重要伎俩,能够用 upstream 和 downstream 这种关系来形容,也能够用其余形式。
在 DDD 中存在多种组织模式和集成模式,如下。
1、单干关系
2、共享内核
3、客户方和供应方开发
4、遵奉者
5、防腐层,简称 ACL
6、凋谢主机服务,简称 OHS
7、公布语言, 简称 PL
8、另谋塔路
9、大泥球
待跟进——上下文映射设计工具,有必要学习和实际
https://contextmapper.org/

外围域

当限界上下文被当作组织的要害战略决策进行开发和运维,则这部分软件模型上外围域,外围域是当下或者将来一段时间企业的主航道,因为企业策略不是变化无穷的,外围域也是动静调整的。
外围域的辨认是一个继续精炼的过程,从一堆混淆在一起的组件中提炼出最重要的内容。——舍九取一的能力
外围域尽管只是一个逻辑概念,然而它体现了器重度关注度,体现了资源的歪斜,架构设计中要清晰的辨认出外围域,并确保在执行中可能把最好的资源投入到外围域中。

子域

子域是畛域更细粒度的划分,依据重要性与性能将畛域分为大抵三类(视我的项目理论状况而定)的多个子域,别离是外围子域、撑持子域和通用子域。外围域是业务胜利的次要促成因素,次要竞争力,撑持子域是撑持外围域的,而通用子域是业务零碎的专用局部。

外围域

同上

撑持域

零碎非核心业务,撑持性质的问题域
撑持子域不须要适度的思考可拓展性和兼容性,可重用性并非技术着力方向,可替代性才是,咱们须要对撑持子域有着明确的契约标准和业务约束条件。

通用域

能够公共复用的问题域

畛域模型

限界上下文是一个显示的边界,在边界外部的软件模型的表白就是畛域模型,畛域模型由模块、聚合、畛域服务组成。

策略设计

次要从业务视角登程,建设业务畛域模型,划分畛域边界,建设通用语言的限界上下文,限界上下文能够作为微服务设计的参考边界。

畛域设计的工作形式
在策略层面,DDD 十分强调针对业务问题的剖析和合成,通过辨认外围问题域来升高剖析的复杂度。在战术层面,DDD 强调通过辨认问题域里的不同业务上下文来进行面向业务需要的组件化。最初在实现层面利用成熟的技术模式屏蔽掉技术细节的复杂度。
战术设计
聚合
畛域事件
畛域服务

聚合根

聚合根是实体,有实体的特点,具备全局惟一标识,有独立的生命周期。一个聚合只有一个聚合根,聚合根在聚合内对实体和值对象采纳间接对象援用的形式进行组织和协调,聚合根与聚合根之间通过 ID 关联的形式实现聚合之间的协同。聚合根的次要目标是为了防止因为简单数据模型短少对立的业务规定管制,而导致聚合、实体之间数据不一致性的问题。首先它作为实体自身,领有实体的属性和业务行为,实现本身的业务逻辑。其次它作为聚合的管理者,在聚合外部负责协调实体和值对象依照固定的业务规定协同实现独特的业务逻辑。

实体

值对象

命令

命令(Command):是执行者发动的操作,形成要件是执行者和行为

MVP(Minimun viable Product)

MVP(Minimum Viable Product), 最小可行性产品, 是研发新产品过程中罕用的一个名词, 意指恰好满足指标用户外围需要的最简模式产品。

BDD- 行为驱动开发(behavior-driver-development)

行为驱动开发是一种麻利软件开发办法,它激励软件我的项目中的开发者、测试和业务人员之间的合作,包含验收测试和客户测试驱动等实际。实例化需要 (Specification by Example) 也是一种用于定义软件产品的需要和面向业务的功能测试合作办法,它和行为驱动开发表白的是同样的概念,采纳的也是同样的实际。
行为驱动开发是在需要梳理阶段对 TDD 测试驱动开发的响应,体现在测试验收方面,验收测试通常指面向业务 (用户) 的(性能)测试,因而它还承载着限界需要阐明和测试代码的职责。验收测试最好应用业务人员、开发人员、测试人员都能了解的“语言”来形容,尽可能防止需要了解的偏差。在麻利开发中,咱们举荐应用用户故事中的验收条件来形容需要,采纳自然语言和“如果 / 当 / 那么”(Given/Wher/Then)的固定格局。
架构边界清晰的益处之一是测试聚焦,让测试聚焦某区域,某档次的测试而发展测试治理

思考与了解

• 动态变化,畛域模型动态变化
• 主权意识的思考:畛域设计强调畛域的限界上下文内的主权意识,团队要承当起主权的捍卫者
• 软件的模型会随着业务的增长继续的突破边界,走向凌乱,继续的畛域设计是在做凌乱的治理,反熵增的,一套面向畛域的软件研发体系,大家依照畛域独立工作,并且反抗凌乱,即零碎能够自带垃圾清理机制,减少零碎的可持续性。
• 一个对象在不同的业务场景都用利用,在这种状况下,该当按业务场景(上下文) 将对象扩散其中,而不是用一个对接去贯通所有业务场景。——这里可能是畛域设计与面向对象的区别,或者说畛域设计是在业务边界内的面向对象设计。见《畛域设计精粹》23 页
• 边界清晰的益处之一是测试聚焦,让测试聚焦某区域,某档次的测试而发展测试治理
参考资料:
https://insights.thoughtworks…

本文转自:https://developer.aliyun.com/…

正文完
 0