【系统架构理论】一篇文章搞掂：领域驱动设计

标签：moc   dom   挑战   down   库存   最好   应该   抽象   通过   

一、什么是领域驱动设计

1.1、面向业务的设计

当我们需要构建一个业务复杂的系统，我们不仅要从技术角度去构建一个稳健的系统，还要从业务角度出发，保证系统能满足业务需求。

架构设计的考虑点：不仅面向技术，更应该面向业务；面对不同的业务复杂度，选择的架构可能不同。

架构师的工作：面对复杂的业务逻辑，需要整合业务和技术才能很好地解决。业务架构驱动技术架构。

一个典型开发团队：新手、中级开发者、高级开发者/架构师（技术架构）、领域专家/产品经理（业务架构）、项目经理

要解决的问题：将复杂的业务架构梳理好，并能为技术架构的设计提供要求或指导。

总结：要进行一个业务复杂系统的架构设计，我们要将技术架构和业务架构整合起来。

1.2、使用领域驱动设计，让业务架构和技术架构能整合起来

既然业务对系统架构有影响，那么如何能将业务语言转化为对技术架构设计有指导意义的信息？

其中一种方法就是领域驱动设计。

领域驱动设计：Domain Driven Design（DDD），一种软件开发的方法学

什么是领域：一个组织的业务开展方式，体现业务价值。

例如：电商网站中的产品、订单、发票、库存、物流；保险公司的保险单、理赔、再保险等。

业务价值：有用的领域模型、抽象的业务定义、更好的用户体验、清晰的模型边界；目的是指导开发出优秀的技术架构。

如何使用DDD：

最终目标：能体现系统业务，又能指导代码开发的一个模型；将设计模型和代码模型很好地结合起来。

通用语言（Ubiquitous Language）：

• 团队成员的行话
• 面向业务
• 表现形式：术语表、文档和图、模型语言。。。
• 面临的挑战：领域专家持续不断介入、开发者对领域的思考方法

综上，我们可以考虑领域驱动设计的设计纬度，从2个方面来看领域驱动设计

设计的策略：

　　关注如何设计领域模型以及对领域模型的划分

• 领域/子域
• 通用语言
• 界限上下文
• 架构风格

　　用于清楚界分不同的系统和业务关注点

设计的技术：

　　关注技术实现的层面教会我们如何具体地实施DDD

• 实体/值对象
• 领域服务
• 领域事件
• 资源库

　　基于技术设计工具按照领域模型开发软件

总结：我们为使业务能指导架构开发，将业务架构与技术架构整合起来，提供的一种解决办法是领域驱动设计，并提出了领域驱动设计的实现策略和实现技术。

1.3、实现领域驱动设计的思路

• 提供一套通用的建模语言和术语
• 展示基于领域趋同的架构设计方法
• 展示实现领域驱动设计的各项关键技术
• 基于具体案例展示设计的策略和技术

二、领域与上下文

2.1、架构的轮回

领域（Domain）：

• 一个组织所做的事情以及其中所包含的一切内容
• 业务范围及所进行的活动
• 开发某个软件时，面对的就是组织的领域

领域模型（Domain Model）：

针对整个业务系统创建的模型

有2种建模方式：

单一、内聚、全功能式：现在不好

功能拆分、服务化、子域：现在越来越流行，如微服务

复杂系统的简单化：功能拆分

拆分关注点：核心功能、辅助功能、第三方功能

拆分后的功能组装：系统集成

功能拆分在领域驱动设计的表现：

拆分关注点：子域

功能组装：界限上下文

2.2、领域/子域/界限上下文

子域分类（一个常见分类）：

核心域：核心业务

支撑子域：专注于业务的某一方面

通用子域：用于整个业务系统

界限上下文：

领域存在于界限上下文中

每个模型概念、属性和操作，在边界之内有特殊含义

拆分上下文的策略：几个可以考虑的角度

根据业务/通用语言（合适）

根据技术架构（不建议）

根据开发任务分配（不建议）

一个团队一个上下文（合适）

2.3、我们的案例

项目计划系统

系统完成对某个项目任务的分解

系统的目的是项目计划的制定

计划的制定通过召开项目会议的方法进行

项目会议的与会人员需要确保身份的有效性

思路：

假想业务流程

围绕领域驱动设计的理念和实践

从策略的设计到技术的设计

层层剖析和演进

初步上下文拆分

2.4、组织和集成模式

大泥球风格（Big ball of mud）

实践中比较常见，随着业务复杂，逻辑堆积，导致结构不清晰，边界模糊

改进：拆分后集成

高层次的架构分析：上游（Upstream）下游（Downstream）

集成的关注点：

上下文之间的关系如何（谁是上游谁是下游）

不同开发团队之间的关系如何

团队之间的关系：组织和集成模式

合作关系：共同成败

共享内核：共享内核显式边界和小型化

客户方/供应方：上游/下游，下游受上游影响巨大；主流模式但不是最好模式

遵奉者：上游无推动力，下游只能妥协或另谋他路

上面几种不属于较好的方法，以下是比较好的方法

防腐层（Anticorruption Layer）：下游客户根据领域模型创建单独一层（可以理解为门面？或适配模式？）

开放主机（Open Host）：定义协议，让别人通过协议访问（如RESTful风格）

发布语言（Published Language）：共享语言完成集成交流（如发布对应API文档）

2.5、上下文集成技术

开放主机服务

上游上下文提供

REST

发布语言

上游上下文提供

XML/JSON/...

消息事件

防腐层

下游上下文提供

2.6、案例中的上下文

OHS/PL/ACL：分别是上面说的3种较好的集成技术

三、领域驱动架构

领域驱动，不仅是策略技术，还包含技术设计

3.1、分层架构

严格分层：只能调下面一层

松散分层：可以随意调用

领域中一般都是包含接口，接口由其他层实现。

如何实现？依赖倒置？Spring框架？

在领域驱动中，分层的概念已经不是那么重要

3.2、平面型架构（重要的架构）

领域驱动推崇

为什么？

因为

1、系统依赖复杂的领域模型，领域模型应该放中间被其它模块依赖

2、有界限上下文，需要和其它服务交互

分层架构不太容易实现

基础架构：

由内而外围绕领域模型展开

应用程序包含业务逻辑

适配器

多种适配器

数据持久化

数据集成

面向结构和Mock机制

3.3、SOA架构

根据适配器的不同行程不同的风格

3.4、RESTful风格

4、CQRS

传统数据操作

命令与查询职责分离

解决领域数据和界面显示的匹配

5、EDA

【系统架构理论】一篇文章搞掂：领域驱动设计

标签：moc   dom   挑战   down   库存   最好   应该   抽象   通过   

原文地址：https://www.cnblogs.com/LiveYourLife/p/9342566.html