DDD实施的一些特定总结 - Thomas

22-10-25 banq

1、有效的软件是与业务挑战相一致的软件
我们所说的一致,是指软件从领域中借用正确的术语,正确阐述业务的关键概念,并尽可能少地避免技术问题带来的意外的复杂性。

2、康威定律不是一个可以选择不接受的选项。
它的作用有点像某些物理定律,如重力的吸引力。我们可以尝试对抗它;-)但它在地球上仍然有效。康威法则是1967年的那个法则,它指出

"任何组织设计一个系统(广义的定义)都会产生一个设计,其结构是该组织的通信结构的副本"。
换句话说,一个软件的结构必然是参与设计的人的交流模式的结果。例如,一个由3个团队开发的编译器很可能分3次工作或有3个不同的模块。
逆向康威手法(ICM)可以让你利用康威法则的优势。这个逆向演习建议根据你想得到的软件架构来定义组织(例如团队的数量)。

3、领域驱动设计并不强加任何组织。
它提供了生存的关键,包括在功能失调的组织中(团队之间相互争斗或相互忽视)。DDD帮助我们理解权力问题和团队之间的社会问题。因此,它是一个解放我们的决定论的工具(因此我认为是一个左翼的工具;-)

4、另一方面,DDD为我们提供了一些工具,使我们能够设计出高效的软件,尽可能地与领域保持一致。其中,限界上下文(BC)的概念建议我们为用途设计模型,并将其包围起来,防止因其他上下文而产生的混淆/假朋友/误解。

5、为了更加协调和高效,DDD还强烈建议我们定期挑战我们的愿景和我们对解决方案的建模。
这也意味着在一个eureka 时刻(称为设计突破)之后,不时地革新和改变模型。这就是为什么我们在这里定期举行Context map会议,与产品人员一起不断完善我们对该领域的愿景。

6、开发团队有脆弱的平衡。
一个开发团队需要大约6个月的共同生活和人际关系,才能真正有效。你从这个团队中增加或删除一个人,它就不再是同一个团队了(见动态重新组队)。就效率而言,我更喜欢那些呆在一起并改变主题的团队,而不是那些只是根据主题进行爆炸/重新分配的团队。当然,如果有人厌倦了他们的团队或他们的主题,应该尽一切努力使他们有可能改变团队(个人的良好状态对我们的集体效率更加重要)。

我们目前的组织和我们在Agicap的团队都相当地隶属于一个或多个Bounded Contexts,以便考虑到问题的复杂性,并将我们各自的业务专长发挥到最小。不时地,一些团队可能有太大的范围,我们需要更好地切割和分配我们的Bounded Context。另一方面,这种BC的划分必须与业务概念保持联系(记住DDD)。

7、只要每个人都尊重Bounded Context的边界,没有什么能禁止在一个做DDD的组织中拥有功能团队。

8、目前,我们更倾向于采用Swarming的做法:一种由几个团队的人组成的工作队,但从一开始就定义了最终产品(工具、api、库)的责任和所有权。它有助于避免 "很好,我们一起做了一些事情,但现在谁来维护它?。
除了在让合适的人根据主题进行合作方面的有效性之外,swarming 通过暂时促进跨团队的人际关系,给我们的组织带来了大量的社会资本(对未来每个人回到自己的团队时超级有用)。

我们目前的产品组织被设定为每个开发团队有一个产品经理(PM),但也许让PM与业务主题有更多联系而不是与他们的团队有联系会很有趣?