AI实践哪家强?来 AICon, 解锁技术前沿,探寻产业新机! 了解详情
写点什么

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:408284
用户头像

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

关注

评论

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

人工智能ChatGPT的多种应用:提示词工程

测吧(北京)科技有限公司

测试

嘉为蓝鲸告警中心:助力大型保险集团实现告警规范管理

嘉为蓝鲸

告警体系 运维工具 IT 运维

为什么说SD-WAN能省钱?

Ogcloud

SD-WAN 企业组网 SD-WAN组网 SD-WAN服务商 SDWAN

火山引擎视频云发布赛事直播方案,延时缩短至1s

新消费日报

淘宝商品详情API接口:高效处理商品信息,提升工作效率

技术冰糖葫芦

API Explorer API 接口 API 策略 pinduoduo API

英特尔软硬协同,优化阿里云通义千问2 AI模型

E科讯

鹏华基金研运一体化平台落地实践,探索数字化转型

嘉为蓝鲸

数字化转型 一体化 一体化平台

淘宝商品列表数据接口实战:构建实时比价系统

tbapi

淘宝商品列表数据接口 淘宝商品数据采集 关键词搜索淘宝接口

德国电动汽车生产:欧洲第一,世界第二

财见

实力认可|心大陆多智能体入围“2024DIIRC大模型十大典范案例”服务商!

心大陆多智能体

面试官:你讲下接口防重放如何处理?

不在线第一只蜗牛

程序员 面试 接口

借助Historian Connector + TDengine,打造工业创新底座

TDengine

数据库 时序数据库

软件测试学习笔记丨Vue路由-编程式导航

测试人

StarRocks vs. Trino: 高并发性能背后的技术优势是什么?

StarRocks

数据库 大数据

【AI法官】人工智能判官在线判案?

AppBuilder

第十二届双态IT用户大会·嘉为蓝鲸平台工程专题研讨会圆满落幕!

嘉为蓝鲸

DevOps BizDevOps 一体化运维

百度面试:如何用Redis实现限流?

王磊

Java 面试

阿里巴巴1688商品详情API返回值应用探索:电商数据驱动的市场趋势预测

技术冰糖葫芦

API Explorer API 接口 API 策略

嘉为蓝鲸监控中心:助力大型运营商解决烟囱工具式监控难题

嘉为蓝鲸

监控 运维工具 IT 运维

2024IT市场权威榜单发布!腾讯云TBDS斩获两大奖项!

腾讯云大数据

TBDS

推荐十个优秀的ASP.NET Core第三方中间件,你用过几个?

不在线第一只蜗牛

asp.net 后端 中间件

低代码开发:智能财务系统开发应用

不在线第一只蜗牛

低代码

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