技术Leader如何落地DDD - 爆改团队（三）-CSDN博客

本文书接上回《技术Leader如何落地DDD - 爆改团队（二）》，全系列合集《技术Leader如何落地DDD》。

背景

按照前文的节奏，技术Leader已经帮助团队在建模设计、技术实现方面建立了可操作执行的原则和规则，团队成员的决策和行为也已经成为了DDD的形状。

这次我们将从团队的协作分工角度，来探讨在DDD实践的背景下，如何最大化地发挥团队成员的能力，使得团队效率充分挖掘。

设计与实现

假如用建筑行业来类比软件工程，可以看作比较核心的两个阶段，设计图纸和施工建造，软件工程中，叫建模设计和代码实现。

理想是丰满的，现实往往却是骨感的，很多开发团队的建模设计和代码实现，往往是落在同一个人身上，甚至是边开发边设计。这种做法，在团队成员技能足够的情况下，是可以确保最终产出满足需求的，但往往团队的配置并不会超配，大部分都是配置不足，往往一个“不重要”的模块，就分给“新手”来做了，这才是常态。

角色

对于业务型系统，建模设计充分的情况下，代码实现基本上可以视作照着图纸“砌砖”，建模设计需要的是足够的业务理解能力以及丰富的建模设计经验，这个岗位最大的特点是“做决定”，决定系统应该怎么满足需求。代码实现则是需要对代码规范和代码框架的掌握，需要做的就是按照图纸来做施工，最大的特点是“做执行”。很显然这两件事所需要的技能是非常不同的，这也意味着，完全可以根据这些能力模型来定义角色。

业务架构师，负责需求分析和建模设计
开发工程师，负责按照模型设计稿实现代码、编写测试

基于这两种角色的定义，技术Leader就可以根据团队成员的能力模型，来定义大家所扮演的角色，谁适合扮演业务架构师，谁适合扮演开发工程师，谁又适合两者都扮演。

两种分工形态

有了团队成员与角色的匹配关系，就可以根据自己团队的状态、规模和工作量的情况，重新定义大家的分工，以期达到最优的产出效率。

在具体的分工定义上，大致有两种策略：

专人专事，业务架构师只做建模设计，开发工程师只做代码实现
一人多角，就是做建模设计，又做代码实现

专人专事的分工方式，适合团队规模相对比较大的情况，可以做细致的分工，这让团队能够最大程度发挥各个角色的优势，缺点是需要充分关注两个角色的协作，业务架构师必须确保建模设计的可实现性，此外也需要注意确保团队成员成长发展的通道，不能把开发工程师锁死在“搬砖”的工作上。

一人多角的分工方式，适合小团队，人不多，没办法很精细地分工，需要团队成员扮演多个角色，既要建模设计，又要自己参与开发工作。这种分工的特点是足够灵活机动，团队成员有比较好的参与感和锻炼机会，缺点就是有可能建模设计能力不足导致模型设计不充分，需要团队制定模型设计评审机制，确保产出的质量。

一些经验

在我的经验中，这两种分工形态都有经历过，而且DDD和非DDD模式的情形也都有案例，这些经验中我发现：

DDD模式下，团队的效率对建模设计的准确性的依赖大大降低了，这是非常令人诧异的，分析之后，我们认为DDD分而治之的原则，帮助团队避免了很多工程上的复杂度问题，这是其核心的作用。
DDD模式下，代码编写变得非常轻松，代码的变更和维护不再是令人恐惧的事情，这得益于DDD范式下的代码组织方式，使得代码类之间的关系和影响变得非常清晰，不再是“剪不断理还乱”的状态，在这样的情形下，在业务系统中写代码工作的“搬砖”特性更加明显地显现了出来，另一方面，也更加增强了团队对建模设计的重要性的认知。