您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
【系统架构理论】一篇文章搞掂:领域驱动设计
 
   次浏览      
 2019-9-3 
 
编辑推荐:
本文来自于mamicode,文章主要介绍了什么是领域驱动设计,2种建模方式,领域驱动的架构等相关内容。

一、什么是领域驱动设计

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

   
次浏览       
相关文章

为什么要做持续部署?
剖析“持续交付”:五个核心实践
集成与构建指南
持续集成工具的选择-装载
 
相关文档

持续集成介绍
使用Hudson持续集成
持续集成之-依赖管理
IPD集成产品开发管理
相关课程

配置管理、日构建与持续集成
软件架构设计方法、案例与实践
单元测试、重构及持续集成
基于Android的单元、性能测试