为什么要让我们的“领域模型”充血裸奔?

作者/分享人:蔡阿斌
向 Ta 提问
英孚教育技术总监,十年敏捷软件开发经验。合著《敏捷开发一千零一夜》;译著《Elasticsearch服务器开发 第二版》。走进一个软件研发经理的日常,这里我们聊需求,技术,敏捷,架构,流程,设计,代码,质量, 运维, 团队…… 我的每次分享,除了内容本身,更希望塑造你对软件开发的思考模型和价值观。技术都是短暂的,价值观永存。

软件行业的童鞋们多多少少都听说过软件开发行业里的下面这些术语:TDD、ATDD、BDD、DDD。入行尚浅的人也许只听过 TDD,经验老道的会发现前面三个还算有关联,最后一个 DDD 乱入。

DDD (Domain Driven Design) 中文“领域驱动设计”,由 Eric Evans 在同名著作中提出,它顾名思义把Domain作为核心来驱动软件的设计。类似的也许比较常见的说法是,要有充血的领域模型(Domain Model),而不能贫血。当然DDD是有一系列实践组成的,让领域模型充血只是其中一个实践而已。本场 Chat 从 DDD 里的第一个 D(Domain)和最后一个 D(Design)入手,探讨如下问题:

  1. 为什么领域模型需要充血? 还裸奔?
  2. 具体如何实现裸奔?
  3. 什么是软件开发里的设计?
  4. 软件总拿来跟建筑比较,它们是可比的吗?
  5. TDD等其它DD们的来龙去脉。

我对这篇文章,以及自己所有文章的期待是:除了技术本身,我更希望从中传递我对软件开发的思考模型和价值观。技术是短暂的,价值观永存。

已有214人预订
预订达标
文章出炉
交流日期
     
17.06.07
17.06.20
17.06.28 20:30
查看文章评论/提问
墓骰明
说实话,这文章真不敢分享出去。打着ddd的旗帜忽悠?既然是道重要,为什么不多写些道上实战经验呢?网上的资料堆砌真没必要。抱歉,说得比较直接。
Maxwell
我一直鼓吹道术双休
石头爸
讲的内容网络上都有看到过,没什么实质收获
桂峰
本来以为有DDD的,其实只是讲了TDD
Hannah Lu
非常精彩的文章,娓娓道来,如我不懂技术的人也觉得收益良多!
Daniel
讲的太棒了,图文并茂,理论深刻而不生硬。资深专家就是不一样。👍
想请教老师一个问题,就是aggrgate里面是否应该直接调用repository,我听过一种说法是aggregat应该只做业务逻辑,对数据的存储应该交给service。不知道老师的观点是怎样?
亮剑
单元测试用例是程序员本人写好,还是专门一个人写好,怎么保证单元测试的质量。文章是想用单元测试实现一遍业务逻辑吧。
王在祥
这个可以申请退款吗?
蔡阿斌: 加我微信
王在祥: 算了,只是觉得文应对题,我是奔这个主题来了解的。可能是我自己没适应你的风格吧。
马里奥的马里奥
没看到太多DDD的内容,看完似乎没什么收获
番茄发烧了
看完感觉说了很多,感觉又什么都没说。
黑色阳光
其实,看完文章,我挺期待评论的,或者说,我挺期待讨论。很难得,毕竟,提出一个问题,比解答一个问题要难得多,接受的质疑也多。先说说我的期待:1.除了道与术,我还希望结合“利”综合考虑,比如时间、人力、风险,希望前辈有时间分享一下,实际的案例,当然要结合道。2.业务的细分纬度,不同的业务领域,划分纬度应该是不同的,例如,存储类业务,我从状态机考虑,身份凭证,我是从生命周期考虑。3.业务间的依赖如何思考,例如,权限否应该成为基础业务还是资源,其他业务是否应该依赖,如何依赖或者解除依赖。暂时先说这些吧
你可能还喜欢
如何设计一个灵活的 MySQL 数据表,应对灵活多变的需求
李岩
Jenkins 自动化构建部署实战
火币集团研发中心
Java 程序员应掌握的 Nginx 实战应用
JPM
带你玩转 JSON
能量架构师
Python Pandas 做数据分析之玩转 Excel 报表分析
WinterLeo
小程序从入门到进阶
loonglong
微信扫描登录