专栏首页DDDDDD战略战术

DDD战略战术

《DDD开篇总结》[1]的前三篇已经阐述了几个内容

1.DDD是什么2.复杂系统的特征3.DDD如何应对复杂系统4.模型概念5.软件开发流程

但一般DDD资料中都会分为两部分讲述:战略和战术,所以按这两种分类,重新归纳整合一下

在讨论战略和战术前,先表述一下“道”

DDD是一种软件开发的方法论,任何方法论,都必须落实到“减少代码复杂度”

那么“道”是什么呢?

一直认为DDD的战略就是道,结果搞错了

软件开发的终极“道”就是“高内聚、低耦合”,它是任何有价值思想和方法的具象

如何才能达到这个终极道呢?

1.DRY2.分离关注点

•2.1. 业务和技术分离•2.2. 业务和部署分离•2.3. 变与不变分离

3.缩小依赖范围4.向稳定方向依赖

战略

DDD战略主要包含统一语言和限界上下文

统一语言

在以往OO开发过程中,会经过OOA,再到OOD,复杂系统中,没有人能全方位了解系统并实现系统,术业有专工,专业人士干伟业事,这是正确的

但分工后,团队合作时沟通至关重要,,在整个系统开发过程中,是有一根主线的,那就是业务知识,业务知识在系统落地前经过层层传递,走样变形是常有的事,从开发人员经过多少次的返工情况就很清楚

如果解决这个问题呢?DDD引入了统一语言,把业务名词含义事先确定好,减少不必要的翻译过程,车同轨,书同文,行同伦

这也消除了业务与技术之间的重复,共同使用业务原语对话

代码就是文档,代码就是领域知识

userService.love(Jack, Rose) => Jack.love(Rose)companyService.hire(company,employee) => Company.hire(employee)

界限上下文

界限上下文囊括了实现道的方方面面,如分离关注点,每个上下文围绕一个关注点,通过整洁架构让各层向稳定方向依赖,合理的划分界限,使各个上下文之间减小依赖

说白了界限上下文就是把一个大系统分而治之

界限上下文算是DDD中的核心知识点,但常被技术人员忽视,对于实用主义的程序员来讲,战术常常更吸引人,其实大到微服务,小到实体类,背后都渗透着上下文的概念

引入限界上下文的目的,不在于如何划分边界,而在于如何控制边界

Alberto Brandolini认为bounded context are a mean of safety(限界上下文意味着安全),safety的意思是being in control and no surprise,对限界上下文是可控制的,就意味着你的系统架构与组织结构都是可控的

显然,限界上下文并不是像大多数程序员理解的那样,是模块、服务、组件或子系统,而是你对领域模型、团队合作以及技术风险的控制

限界上下文是“分而治之”架构原则的体现,我们引入它的目的其实为了控制(应对)软件的复杂度,它并非某种固定的设计单元,我们不能说它就是模块、服务或组件,而是通过它来帮助我们做出高内聚低耦合的设计。只要遵循了这个设计,则限界上下文就可能成为模块、服务或组件。所以,文章《Bounded Contexts as a Strategic Pattern Beyond DDD》才会写到:“限界上下文体现的是高层的抽象机制,它并非编程语言或框架的产出工件,而是体现了人们对领域思考的本质。”

战术

对于开发人员而,战术是最实用的,比如聚合、实体、值对象、工厂、仓储、领域事件等等, 使用这些战术组件建模工具,DDD满足了软件真正的技术需求。这些战术设计工具使开发人员能够按照领域专家的思维开发软件

战略部分讲了,界限上下文的思想是核心,在战术组件中都有体现,比如实体,实体就是一个最小上下文,聚合就是相对实体大一点的上下文

但残酷的现实是,花费了大量的精力来学习这些DDD战术组件,却在实现项目中却用不上,为什么呢?因为事务脚本思维太深,分层也大多是从技术角度出发,没有抽象出领域模型,也就是没有OO抽象,没有一个完整的对象,实体都没有,像工厂,值对象也就成了水中花

这也是我们虽然常重构代码,也不过是大类变小类,大函数拆分成小函数,符合一下代码规范,但对整个项目而言,其实没有实质性改进

如何能有实质性改进,对于复杂系统如何运用上这些战术组件呢?

此时,结构性思维发挥作用了

第一步:过程分解,把一个复杂的系统按流程拆解成各个阶段和步骤,这也是事务脚本的强项

第二步:对象建模,过程性拆解虽然可以降低了开发难度,但领域知识被割裂,代码的业务语义也不明确,在这方面OO是强项,提升代码复用性和内聚性

结合这两步,自上而下的结构化分解+自下而上的面向对象建模,过程化分析更好地清理了模型之间的关系,而对象模型提升代码复用性和业务语义表达能力

总结

DDD是一套很好的方法论,有时我们常在理论纯洁性与实战性之间徘徊。这也许是初级阶段常有的纠结点

DDD有适用场景,事务脚本有存在的优势

不能因为现在人们开口闭口都是DDD,就硬要开展DDD

DDD难以落地除了本身带来了很多概念,还需要团队整体素质

软件开发没有银弹,不能偏执于一种理论,实际开发是场硬仗,像混合格斗一样,不在于一招一式是哪门哪派,制敌才是终极目标,所以需要根据自身情况进行裁剪,灵活运用

References

[1] 《DDD开篇总结》: http://www.zhuxingsheng.com/blog/ddd-opening-summary.html

本文分享自微信公众号 - 码农戏码(coder-game),作者:朱先生

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-11-16

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 为什么DDD难以教授?

    在日常工作中使用领域驱动设计的工作越多,就越能面对教学的难度。这是怎么回事?DDD经常被误解!我们也可以认为掌握DDD一件复杂的事情,需要掌握大量的知识和实践。...

    物流IT圈
  • 业务架构能否被DDD带起一波?

    两年前偶然接触了DDD(领域驱动设计),虽然读过了这方面最重要的两本著作,但是一直没有机会真正实践,在自己做过的业务架构设计项目中曾想做过一次尝试,但最终没能进...

    用户6900693
  • DDD实施经验分享—价值导向、从上往下进行(圈内第一个吃螃蟹DDD实施方案)

    阅读目录: 1.背景 2.从业务开始 3.从战略到战术 4.借助外力推动研发(QA、领导、自动化测试) 5.领域模型与SAAS平台的内核(价值最大化) 6.最后...

    王清培
  • 一文一点 | 你认为什么是DDD设计方法的基石

    所有的软件最终是要解决用户问题的,而软件的落地最终是要靠一行行的代码垒起来的,那么这个时候从识别出用户问题到代码实现之间就需要一种过度,而架构设计就是这种过度的...

    王新栋
  • 读《中台架构与实现》

    最早是在极客时间知道欧创新老师的,我也是他的课程《DDD实战课》的订阅者,后来欧老师基于这门课程做更多的实践与思考,完成了《中台架构与实现:基于 DDD 和微服...

    oec2003
  • 解惑领域驱动设计的若干问题

    作者 | 张逸 最近重读Eric Evans的经典《领域驱动设计》,正如Eric提倡我们要去发现隐式概念一般,这次重读也让我发现了许多隐藏的DDD知识。恰好今...

    张逸
  • 白话中台番外篇:DDD、EventStorming与业务中台

    刚刚结束的2019年领域驱动设计峰会(DDD China Conference 2019),已经是DDD-China的第三年了,也是我参加的第二年,还记得去年分...

    ThoughtWorks
  • 领域驱动设计门槛很高,没有深厚的面向对象编码能力很难实践成功

    时间是人类最宝贵的资源。时间是有限的、不可再生的,你可以用钱买任何东西,却买不了时间。技术,就像时尚,在以光速在变化着。为了赶上它,我们需要跑的非常快。但是这个...

    春哥大魔王
  • 重新温习软件设计之路(5)

    本文是我学习课程《软件设计之美》的学习总结第五部分,记录对于DDD领域驱动设计方法的整体理解。

    Edison Zhou
  • 领域驱动设计学习之路—DDD的原则与实践

    本文是我学习Scott Millett & Nick Tune编著的《领域驱动设计模式、原理与实践》一书的学习笔记,一共会分为4个部分如下,此文为第1部分:

    Edison Zhou
  • DDD实战课--学习笔记

    我认为,要想应用 DDD,首要任务就是要吃透 DDD 的核心设计思想,搞清楚 DDD、微服务和中台之间的关系。中台本质是业务模型,微服务是业务模型的系统落地,D...

    郑子铭
  • 如何学习领域驱动设计

    封面图:张子瞻的绘画,用丙烯颜料表达了蓝色的海、白色的波浪、棕黄色的沙滩以及墨绿色的树林。

    张逸
  • 从架构演进谈 DDD 兴起的原因以及与微服务的关系

    我们先不讨论DDD的定义, 先梳理一下DDD火起来的背景, 根据我学习的套路, 永远是为什么为先,再是解决什么问题,是什么东西, 最后如何使用。我们都知道这些年...

    孙玄@奈学教育
  • DDD实现之路

    编者按:这篇文章最早撰写于2014年,作者也是《实现领域驱动设计》的译者。几年过去了,DDD在坊间依然方兴未艾,然而它的复杂性所引发的误解也层出不穷。对于一些基...

    ThoughtWorks
  • 第三章、快速开始 -【1/3】战略设计

    DDD的应用实践是一个认知的过程,在实践时团队成员尽量保持同一水平的认知,通俗来说,就是错也要错的一致,同时在落地时要以多数人的认知为基准实施,不能以认知程度高...

    yd
  • Golang领域模型开篇,当Go遇上DDD

    我本身就是一个不太会拒绝的人,这点和雷军相似。最近一周,有网友说要给我投稿,内容见本文。所以,本文是转载的一篇文章,有喜欢的可以深入学习!

    业余草
  • .Net微服务实战之技术架构分层篇

      上一篇《.Net微服务实战之技术选型篇》,从技术选型角度讲解了微服务实施的中间件的选择与协作,工欲善其事,必先利其器,中间件的选择是作为微服务的基础与开始,...

    陈珙
  • DDD战术篇:领域模型的应用

    领域驱动设计DDD在战术建模(后文简称建模,除非特别说明)上提供了一个元模型体系(如下图),通过这个元模型我们会对战略建模过程中识别出来的问题子域进行抽象,而通...

    ThoughtWorks
  • 领域驱动落地方法论

    其实解决一个复杂领域系统的方式不只限于编码架构,我们同样需要从一些外溢的环节去考虑应对这种复杂度。

    春哥大魔王

扫码关注云+社区

领取腾讯云代金券