码迷,mamicode.com
首页 > 其他好文 > 详细

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

时间:2018-09-27 10:37:44      阅读:610      评论:0      收藏:0      [点我收藏+]

标签: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

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!