标签归档：DDD

从领域驱动设计（DDD）到技术团队管理的 6 点思考

发表回复

领域驱动设计(Domain-Driven Design， DDD)是一种软件开发方法，由 Eric Evans 在 2003 年出版的同名著作《领域驱动设计：软件核心复杂性应对之道》中提出。DDD 的核心思想是，相比技术实现，业务领域知识对软件项目的成功更为关键。因此，开发团队应该将主要精力投入到理解和建模业务领域，并以此指导软件设计和开发。

DDD 主要解决以下问题：

  1. 业务复杂性：现实世界的业务领域往往非常复杂，涉及各种业务实体、业务规则和业务流程。领域建模通过将复杂的业务领域划分为若干个界限清晰的子领域，并提炼出每个子领域的核心概念和关系，来管理和应对业务复杂性。

  2. 沟通鸿沟：业务专家和技术团队往往使用不同的语言和思维方式，导致沟通障碍和理解偏差。领域建模强调建立一种团队共享的统一语言，通过将业务概念和规则显式地表达在领域模型中，促进业务和技术之间的有效沟通。

  3. 软件弹性：随着业务的不断发展和变化，软件系统也需要随之演进。但是，如果软件设计没有准确反映业务领域，后续的变更就会变得困难和混乱。DDD 通过识别出领域中的不变量和变化点，并使用合适的设计模式和架构风格来封装和管理变化，提高软件的弹性和可维护性。

为了解决这些问题，DDD 提出了一系列原则和实践，包括：

  • 界限上下文：将复杂的业务领域划分为多个界限明确的上下文，每个上下文对应一个特定的业务语境。
  • 统一语言：在每个界限上下文中，开发团队和领域专家应该使用同一套语言来描述业务概念和规则。
  • 领域模型：通过分析业务领域，提炼出核心的业务概念、业务规则和业务逻辑，并用对象模型来表示。
  • 分层架构：将软件系统划分为用户界面、应用层、领域层和基础设施层，并确保依赖关系始终朝向领域层。

DDD 的发展历程大致如下：

  • 20 世纪 90 年代，随着面向对象分析与设计(OOAD)的兴起，人们开始关注如何将现实世界的业务概念映射到软件对象中。
  • 2003 年，Eric Evans 出版了《领域驱动设计》一书，系统地阐述了领域建模的原则和实践，标志着 DDD(Domain-Driven Design)的诞生。
  • 此后，DDD 逐渐受到业界的广泛关注和应用。一些知名的 DDD 实践者，如Vaughn Vernon、Udi Dahan 等，通过著作和演讲进一步丰富和发展了 DDD 的理论体系。2014年，Vernon 出版了《实现领域驱动设计》一书，详细阐述了 DDD 在架构设计、领域建模、代码实现等方面的最佳实践，成为 DDD 实践者的重要参考。
  • 近年来，随着微服务架构的兴起，DDD 在微服务设计中得到了广泛应用。一些新的概念和模式，如事件风暴、限界上下文、命令查询职责分离(CQRS)等，进一步扩展了 DDD 的实践边界。

近年来，DDD 持续受到关注，并在实践中不断发展：

  1. 事件风暴(Event Storming)：由Alberto Brandolini提出，通过识别领域事件来快速建立领域模型，加速了DDD的建模过程。
  2. CQRS和事件溯源(Event Sourcing)：将领域模型的读写职责分离，并将所有的状态变更记录为事件，提高了系统的性能和扩展性。
  3. 领域故事(Domain Story)：将用户故事(User Story)提升到业务领域的层次，用业务语言描述系统的功能需求，加强了业务视角的引入。
  4. 领域驱动的微服务设计：以 DDD 为指导，从业务领域的角度识别和拆分微服务，提高了微服务的内聚性和自治性。

当前，领域建模和DDD 已经成为应对复杂业务系统设计的重要工具和方法论。以下是一些最新的发展趋势：

  1. 结合敏捷实践：DDD 强调在开发过程中持续深化对领域的理解，并通过频繁的反馈和调整来完善领域模型。这与敏捷开发的迭代优化理念高度一致。当前，越来越多的团队尝试将 DDD 与 Scrum、看板等敏捷实践相结合，通过跨职能团队协作、领域故事映射(User Story Mapping)等技术来加速领域建模的过程。

  2. 领域事件驱动：随着 Event Sourcing 和 CQRS 等架构模式的普及，领域事件(Domain Event)成为连接领域模型与技术实现的重要媒介。通过显式定义领域事件，并以事件驱动的方式编排业务流程和数据同步，可以提高系统的扩展性和性能。

  3. 开发工具支持：越来越多的建模工具和开发框架开始提供对DDD的原生支持。例如，EventStorming 工具支持在线协作完成事件风暴;MPS(Meta Programming System)等语言工作台支持以领域特定语言(DSL)的方式直接表达领域模型;Axon、Eventuate等框架提供了事件溯源和CQRS的开箱即用支持。这些工具的成熟，大大降低了DDD的实施门槛。

  4. 企业级应用：DDD 典型地应用于单一企业内部的复杂业务系统。而随着企业数字化转型的深入，DDD 在企业级应用架构中也开始发挥越来越重要的作用。通过运用 DDD 原则，建立清晰的业务领域边界和上下文映射，可以指导企业级应用的领域划分、系统解耦、服务化演进等架构设计工作。

通过上面的内容我们对于领域驱动设计有了一个初步的认知，DDD 为设计和开发复杂业务系统提供了行之有效的指导原则和实践指南。

那从技术团队管理的角度来看，有哪些相似点，又有哪些不同，DDD 的原则及其解决问题的过程对于技术团队管理者来说又有哪些借鉴的地方，对此有如下的 6 点思考：

1 管理复杂度

DDD 的核心在于管理业务复杂性。通过将复杂的业务领域划分为若干个界限清晰的子领域，并在每个子领域中提炼出核心业务概念和业务规则，DDD 帮助我们深入理解业务，并将其转化为可执行的软件模型。这一点对于应对日益复杂的业务需求至关重要。

DDD 面对复杂的业务领域，会进行领域划分，识别出核心域、通用域、支撑域等不同的子领域。通过划分领域边界，我们可以更好地管理复杂性，分而治之，让每个子领域都有明确的职责和边界。同时，领域边界划分也有助于识别领域内的关键概念、业务规则和约束条件。

技术团队管理同样面临复杂性的挑战。随着团队规模的扩大和业务需求的增长，团队内部的沟通协作、技术决策、资源调配等问题日益复杂。

管理者需要采用合适的组织结构和管理实践，将复杂的团队工作划分为可管理的模块，并在模块间建立清晰的职责边界和接口协议。

并且划分团队边界和职责，根据系统架构和业务需求，设计出合理的团队结构和职责分工。每个团队或角色都应该有明确的边界和交付物，避免出现职责交叉或责任真空的情况。通过职责边界划分，团队成员能够专注于自己的工作，提高工作效率和质量。

领域边界划分和团队职责划分的相似之处在于，它们都是为了应对复杂性，通过「分而治之」的方式来管理复杂度。

2 统一语言

DDD 强调在每个界限上下文中建立统一语言，即业务专家和开发团队应该使用同一套语言来描述业务概念和业务规则。统一语言有助于消除业务理解上的歧义，减少需求遗漏和错误理解，提高沟通效率。

在技术团队管理中，统一语言也扮演着类似的角色。团队成员来自不同的背景和专业，彼此之间容易产生理解偏差。技术团队管理者需要在团队内部形成一套统一的技术语言体系，包括架构原则、设计模式、编码规范、质量标准、开发语言等。确保所有人对工作内容有相同的理解。

统一的技术语言有助于提升团队的协作效率，减少技术债，促进知识共享和经验传承。

统一语言在领域建模和技术团队管理中的共通点在于，它们都强调语言的一致性对于沟通效率和工作质量的重要性。

这本质上是一个成本问题，减少过程中的沟通成本，通过统一语言实现有效协作，正所谓「言语齐，则民聚；言语不齐，则民散」。

业务统一语言强调与领域专家的有效沟通，而技术统一语言更强调团队内部的协作。二者需要相互配合。

3 分层架构的设计

DDD 提出了分层架构的设计原则，即将软件系统划分为用户界面、应用层、领域层和基础设施层，并确保依赖关系始终朝向领域层。

分层架构有助于隔离业务逻辑与技术实现，保持领域模型的纯粹性，提高系统的可测试性和可维护性。

技术团队管理同样强调分层管理。随着团队规模的增长，扁平化管理将变得难以为继。管理者需要在团队内部建立起适当的管理层级，并在各层级间合理划分职责和权力。

过于复杂的层级会导致信息传递失真和决策迟滞，而过于扁平的结构又可能让管理失控。管理者需要在二者间寻找平衡。

分层架构是管理复杂性的有效手段。但软件分层架构强调上层依赖下层，而管理分层强调上层指挥下层。

软件分层追求的是关注点分离和依赖最小化，管理分层追求的是指挥与协作的最优化。二者分工不同，但目标一致：通过恰当的分层，让复杂系统变得可控和高效。

4 持续迭代优化

DDD 强调通过持续迭代和反馈来优化领域模型。

这是一个渐进的过程，团队在每个迭代周期中，都要对已有的领域模型进行评估和改进，通过引入新的业务洞见、技术创新等来持续迭代优化模型。这种持续优化的实践，确保了领域模型能够随业务变化而演进，始终保持与业务需求的紧密匹配。

技术团队管理同样需要持续迭代优化。优秀的管理实践并非一蹴而就，而是在持续实践中逐步完善。

管理者需要在每个迭代周期中，评估现有的管理实践，识别可以改进的地方，并基于反馈不断优化。彼得·德鲁克说：「管理的本质不在于知而在于行」。

常规我们会通过定期的回顾总结会议，团队成员分享工作中的经验教训，识别出可以改进的地方，并制定行动计划。当然，不局限于总结会议，可以是沙龙或者其它非正式一些的方式，但是组织逻辑还是要按高效会议的逻辑组织。

通过持续不断的自我优化，团队能够在实践中不断成长，提高工作效率和质量，适应不断变化的技术挑战，始终保持与团队需求的动态匹配。

持续迭代优化是 DDD 和技术团队管理的共同追求。二者都认识到，在复杂多变的环境中，唯有持续改进，才能保持竞争优势。但 DDD 关注的是领域模型的持续优化，技术团队管理关注的是管理实践的持续完善。二者殊途同归：领域驱动为优化指引方向，管理实践为优化提供载体。

5 平衡战术和战略目标

DDD 在战术设计和战略设计间寻求平衡。战术设计关注软件的实现细节，如聚合、实体、值对象等；战略设计关注高层的业务架构，如界限上下文、上下文映射等。

DDD 认为，只有战术与战略协调一致，才能实现业务目标。过度关注战术实现，可能导致偏离业务方向；过度关注战略规划，可能导致落地困难。需要在二者间寻求平衡。

技术团队管理同样需要平衡战术执行和战略规划。战术执行确保团队高质量、高效地完成当前的项目任务，交付满足业务需求的软件产品，关注当下的交付质量和效率，战略规划关注团队成员的能力成长，通过培训、指导等方式提升团队的整体技术实力，关注长期的技术演进和团队发展。

管理者需要在二者间权衡取舍：过度关注战术执行，可能会陷入短期主义，积累技术债；过度关注战略规划，可能会脱离现实，导致执行力不足。

优秀的技术团队管理者，需要在战术执行中体现战略意图，在战略规划中考虑战术现实。

平衡战术和战略是 DDD 和技术团队管理的共同诉求。二者都强调在理想和现实、当下和未来间寻求平衡。DDD 在战术实现和战略规划间权衡，技术团队管理在短期目标和长期发展间平衡。二者殊途同归：领域驱动为战略导向，技术驱动为战术赋能。

6 聚焦核心价值

DDD 的终极目标，是通过领域建模和设计，让软件聚焦和体现业务的核心价值。通过提炼核心域和通用域，DDD 让团队优先保证核心业务的软件质量和交付效率。

通过聚焦核心领域，我们可以将有限的资源投入到最能体现业务价值的地方，构建出反映企业核心竞争力的领域模型。

同时，对于非核心的通用域和支撑域，我们可以采用购买、外包等方式来降低复杂度，聚焦核心。

技术团队管理需要聚焦团队的核心竞争力。面对有限的资源和无限的需求，管理者需要做出取舍，让团队聚焦最能体现其专业优势和商业价值的领域。

对非核心业务，可以考虑外包或购买现成解决方案；对通用功能，可以考虑复用或使用开源方案。

管理者需要带领团队持续思考：什么是我们的差异化优势？什么是我们的核心竞争力？ 并围绕这个核心持续打磨和升级。

聚焦核心价值是 DDD 和技术团队管理的终极诉求。DDD 聚焦领域核心，技术团队管理聚焦团队优势。聚焦价值，体现价值。

7 小结

DDD 提供了一个解析和管理复杂性的思维框架，其核心理念和实践，如持续迭代优化、应对变化和不确定性、平衡战术和战略目标、聚焦核心价值、领域边界划分、分层架构等，都对技术团队管理有深刻启示。

这启示我们以系统性思维审视复杂性，以适应性领导拥抱变化，以持续成长的心态追求卓越，以跨界协作的方式创造价值。

正如 Albert Einstein 所言:”复杂的问题不能用产生它的思维方式来解决。” 领域驱动设计给了我们一种突破旧有思维方式的新视角。

技术团队管理的艺术，在于洞察人性，激发潜能。而领域驱动设计的智慧，在于洞察业务本质，拥抱技术变革。二者相互交织，共同指引我们在不确定性中前行。

作为技术管理者：

  • 我们要成为连接业务与技术的「架构师」，引领团队用创新点亮未来;
  • 我们要成为引领变革的「领航员」，带领团队在不确定中破浪前行;
  • 我们更要成为成就他人的「园丁」，营造持续成长的土壤，让每个生命绽放光彩。

以匠心，以爱心，以卓越之心

以上