写点什么

DDD 返工

  • 2018-10-01
  • 本文字数:1872 字

    阅读完需:约 6 分钟

本文要点

  • 类似领域的两个独立项目,都使用 DDD 实现,这提供了一个有趣的机会,可以从失误中学习,从而做得更好。
  • 有界上下文没有用在第一个项目中,因为那需要客户认同构建更小的系统。
  • 这两个项目的最大不同是采用有界上下文以及创建一个反腐层。
  • 通用语言仅限于有界上下文中。虽然有些术语可以在一个宽泛的领域内使用,但是定义会大相径庭。

Explore DDD 2017 大会上, Jimmy Bogard 谈到,他们获得了一个少有的机会,使他们可以在一个项目中进行他所谓的“返工(do-over)”。虽然不是完全从头开始重写,但他是参与了相关公司的两个非常类似的项目。InfoQ 采访了 Jimmy,了解他们如何运用从第一个项目中获得的经验教训使第二个项目取得更大的成功。

InfoQ:“如果我们可以把一切重新来做……”,这是那些从事大型软件项目开发的人常说的一句话。那种事后智慧通常可以为将来的项目提供指导。你们获得了一个少有的机会,可以在几年内实际从事两个客户和领域都几乎相同的项目。您能介绍下你们的客户、项目和主要目标吗?

Jimmy Bogard:最终用户是德州政府雇员,跨越许多不同的地理边界。第一个系统是面向青少年的案件管理系统,涉及法律程序的各个方面。这个青少年系统的整体目标不是惩罚,而是为违法的孩子提供帮助。客户包括州主要都市地区的县以及一个负责监督每个县的程序的州属机关。

第二个系统限制更多一些——为德州的县检察部门提供一个仅供他们使用的单一系统,而且仅用于成人程序。

InfoQ:当第一个项目在 2007 年启动时,DDD 还是一个相当新的理念。您的团队、客户对于 DDD 概念,如领域模型、通用语言、有界上下文,处于什么经验水平上?

Bogard:技术负责人(我自己)和架构师有几年构建 DDD 系统的经验。我的第一个 DDD 项目是在 2005 年,我还向那个项目的产品团队介绍了 XP 和 Scrum。对于有界上下文,我们就没有多少经验,虽然社区那会更关注结构化模式。

InfoQ:在这个过程中,您认为你们的经验水平导致了什么重大的失误吗?例如,所遵循的设计和开发实践导致了不必要的软件复杂度。

Bogard:不,没有。设计概念需要经过几个项目的迭代才会变成今天的样子。最大的错误——没有有界上下文——那会需要客户认同构建更小的系统。那没有发生。此外,我们非常谨慎,只构建我们需要的东西,并且根据我们知道的假设进行设计。由于范围太大,所以我们知道,如果没有完成比赛的希望,我们就不可能获得金牌,因此,我们尽力推迟复杂的需求。

InfoQ:该系统的构建和付款都是在一个机构完成的,但需要满足其他各种组织的需求。这导致领域模型设计做出了什么妥协吗?使用的语言真的是通用的吗?

Bogard:当然,这导致了设计上的妥协。有时候,我们的设计有点天真,一旦我们了解了一个方面的所有领域,我们就会看到,其设计与系统的其他部分基本上是不相容的。因此,我们就得妥协。在语言方面,我们发现,虽然术语是通用的,但背后的意思可能不同。只有把各个领域的专家都聚到一个屋里来,那才会显现出来。我们遇到过,每个人都认为他们同意了,但在会议结束时,没人同意。

InfoQ:在您的第二个项目中,方法上有哪些主要的差别,尤其是从 DDD 的角度来看?这些差别是如何反映在现实生活中的?

Bogard::最大的差别是采用了有界上下文。我们在我们的系统和其他系统之间构建了一个反腐层,这样,当其他机构要和我们的系统连接时,就可以使用他们熟悉的术语和设计,但是我们内部会转换。例如,执法人员和检察人员都有“违法(offense)”的概念。在实际的系统里,我们会分成两个概念,因此,有两个名为“违法”的领域对象——一个面向执法人员,一个供我们自己使用。把它们分开,意味着我们可以单独修改其中一个而不影响另一个。

InfoQ:和严格遵循模式的第一个项目不同,您的第二个项目采用了更为务实的做法。对于完成项目满足客户需求并保证代码高质量、可维护,您有什么建议吗?

Bogard:那些项目是马拉松,而不是冲刺。要采用更偏向产品思维而不是项目思维的方法,设计要长远考虑,但要围绕我们已经做了验证的假设。如果我们有了新的发现,那么我们要制定计划把那些变化包含进来,而不是让我们的设计随着时间推移慢慢坏掉。

InfoQ:有些读者希望更多地了解您遵循的设计建议,您有什么要推荐的吗?

Bogard: SOLID 架构:分片而不是分层。

关于受访者

Jimmy Bogard 是 Headspring 的首席架构师,《MVC 实战》一书的作者。同时,他还是一名国际演讲者和多产的 OSS 开发人员。他是分布式系统、REST、消息传递、领域驱动设计、CQRS 方面的专家。

查看英文原文: The DDD Do-Over

2018-10-01 18:407951
用户头像

发布了 1008 篇内容, 共 387.9 次阅读, 收获喜欢 344 次。

关注

评论

发布
暂无评论
发现更多内容

低代码开发助力中小企业数字化转型难度持续降低

EquatorCoco

低代码

从混乱到可控:非结构化数据在远程监造中的作用

奇点云

人工智能 软件 IT 制造业

HarmonyOS NEXT开发之ArkTS自定义组件学习笔记

威哥爱编程

HarmonyOS ArkTS HarmonyOS框架 HarmonyOS NEXT

面试官:go中的singleflight是如何实现的?

王中阳Go

Go 后端 面试问题

CST电磁仿真技术:引领时代发展的前沿

思茂信息

电磁 仿真 cst

数据结构 - 队列

EquatorCoco

数据库 数据结构

融合大模型技术,激发开发新动力,IDE分论坛成功举办

科技热闻

约80%开发效率提升,原生鸿蒙政务、文旅行业样板间专区上线

最新动态

2025北京智能科技产业博览会(世亚智博会)

AIOTE智博会

智博会 世亚智博会 智能科技展 智能科技博览会

阿里巴巴中国站商品详情API返回值的未来发展趋势

技术冰糖葫芦

API 接口 API 文档 API 测试 pinduoduo API

90后程序员的职业成长漫谈

京东科技开发者

BlockCoin部署进展公示

科技热闻

第三届OpenHarmony技术大会OS内核及视窗分论坛圆满举办

科技热闻

三亚等保测评公司有哪些?在哪里?

行云管家

等保 等级保护 三亚

测试聊并发-入门篇

京东科技开发者

文献解读-Chromosome-Level Genome Assembly of the Green Peafowl (Pavo muticus)

INSVAST

基因数据分析 生信服务

GenAI 时代的软件架构和设计:机遇、挑战和未来

俞凡

人工智能 架构

AI 大模型应用开发实战营总结

Kevin

AI大模型 openai 向量数据库 LLM langchain

释放无限潜力:Databend 存算分离架构如何让企业数据管理焕然一新?

Databend

存算分离架构

淘天集团5篇论文入选NeurIPS,阿里妈妈自动出价比赛决赛白热化

新消费日报

运维黑匣子作用是什么?堡垒机是运维黑匣子吗?

行云管家

运维 堡垒机 黑匣子

DeFi复兴:让DeFi再次伟大

区块链软件开发推广运营

交易所开发 dapp开发 链游开发 NFT开发 公链开发

通过Forcebot压测实践简述“并发模式”与“RPS模式”两种模式的区别

京东科技开发者

LED会议屏:提升会议体验的利器

Dylan

科技 LED display LED显示屏 技术 优化体系

5分钟了解软件开发的20项基本原则

俞凡

架构 最佳实践

一站实现高效开发,鸿蒙生态伙伴模板&组件专区全新上线

最新动态

软件测试学习笔记丨接口自动化框架

测试人

软件测试

第70期 | GPTSecurity周报

云起无垠

中国3-6岁儿童人群需求与行为洞察

易观分析

某市驾驶培训监管服务平台 GreatSQL 数据库适配之旅

GreatSQL

2024后量子区块链峰会:连接Web3、安全与后量子密码学的未来

区块链软件开发推广运营

交易所开发 dapp开发 链游开发 NFT开发 公链开发

DDD返工_研发效能_Thomas Betts_InfoQ精选文章