-
开发人员热衷于技术而不是深入了解业务。这是技术人员的职责使然,一个不高级的开发,通常他的业务经验不重要;一个高级的开发,通常因为竞业,也无法继续干类似的业务。所以开发人员对业务天然的没有足够的兴趣。但是开发过程中,对业务不够熟悉,很容易发现开发做了半天得到的,并不是用户和产品想要的;或者下次再有需求的时候,技术上的改动特别大,成本很高。
-
业务协作不畅,一个需求提到好几个团队都能做,但是开发过程你推我我推你,需求一拖再拖,有时候项目中期还得找其他团队求资源。
-
对项目工时的估计占用了不少精力,还不准确。估时这件事能成为管理层和开发人员之间的拉锯战。
-
服务之间紧耦合,牵一发而动全身,一个非核心的业务抖一抖,客户都说没法用。
-
找到边界:让设计系统的人知道一个业务的边界在哪里。只有知道边界在哪里,才能在需求到来的时候,轻易地找到相关团队,各个业务之间也才能真正解耦,降低非核心功能对核心功能的影响。
-
知识获取:保证设计系统的人能够低成本地了解业务,让大家在怎么做,怎么验收方面达成一致。在此基础上,还可以免费得到一款评估时间的工具,项目的交付就更有把握。
-
TDD:驱动测试开发
-
BDD:行为驱动开发
-
ADD:不是单词Add,而是API驱动开发
-
DDD:领域驱动设计
-
把一些实体和值对象放一起,称为聚合。
-
利用领域事件通知相关系统。
-
邀请领域专家和开发人员
-
每个成员都应该以开放的心态参与讨论,不必追求正确和速度。
-
各种颜色便利贴,正方形的。一般一个便利贴只会写几个词。
-
每个人都有黑色的马克笔。
-
最好有一面至少10米长的墙并且铺上白纸。最好建模的几天时间内保持每次讨论的结果一直保留并供下次讨论使用。
-
创建领域事件强调我们首要关注的是业务流程,而不是数据和结构
-
把每个领域事件写在一张便利贴上,应该是动词的过去式。
-
把写好的便利贴按照时间顺序放到建模平面上,从左往右逐步发生。
-
并行发生的领域可以上下排列,不明白时机的事件可以单放在某个单独的位置。
-
如果发现了问题点,可以用红色的便利贴上,并用一段文字解释是什么问题。
-
领域事件最终会触发一个执行的流程,每个流程都应该命名并记录在浅紫色的便利贴。需要从领域事件画个箭头指向这个流程。支队核心域中非常重要的细粒度事件进行建模。
-
创建领域事件的便利贴是浅蓝色的。
-
触发事件的便利贴放在触发的事件左边,会有很多成对出现的命令和事件。但是也有不是命令触发的事件,比如时间触发的事件。
-
如果存在一个执行动作的特定角色,那么可以在命令左下角使用亮黄色的便利贴记录角色名称。
-
命令也可以触发流程。
-
在命令和事件之间画出线条
-
按照时间顺序,将命令和事件的关系处理好
-
一个命令可以带来多个事件
-
DDD一定要用微服务?不,其实多个域在同一个进程也没问题,只要满足一个聚合在一个事务内保护就没有问题。
-
DDD的架构是稳定的?这么问的人一定没有理解什么叫做领域驱动。当领域发生演化的时候,系统的改变肯定不会小。比如电商系统里收货地址,可能一开始只是没有业务意义的值对象,但是后续有了管理,比如家庭,公司,然后反过来绘制画像,精准推荐……地址有了管理系统,那就不再是值对象了。但是DDD能保证在每期迭代中,需要做的工作都是最贴合当前需求的,并且当下一迭代到来的时候,做的改造工作量也是各方可以理解的。与之相反的所谓提前规划,通常会演化为把之后若干迭代的部分放到当前迭代,而且当未来没有按照预定的方式改变时,这些工作可能还是无效的。
原文始发于微信公众号(分布式实验室):走近DDD
- 左青龙
- 微信扫一扫
- 右白虎
- 微信扫一扫
评论