从本质上讲，所有模型都是错误的，但有些模型是有用的。

——乔治·博克斯（George E. P. Box）

领域建模

扩展SAFe指南中的领域建模

概述领域建模是一种重要的软件工程方法，用于描述和建模现实世界中的实体及其关系。这种方法有助于理解问题域空间，为系统设计提供基础，并促进系统级需求的理解。

领域建模的重要性- 系统级需求理解：识别领域实体及其关系，为理解提供有效基础。- 设计可维护性、可测试性：帮助设计出易于维护和测试的系统。- 增量开发：支持系统的增量开发。

领域建模在SAFe中的角色- 团队与项目群连接：域建模连接到团队、项目群、大型解决方案和项目组合级别的积压工作项。- 通用语言：为整个组织提供通用语言。- 非功能性需求（NFR）：与NFR紧密联系，有时采用替代设计方法满足NFR。

敏捷组织的设计模式- 敏捷友好型设计：提供使用敏捷友好型设计模式和方法的机会。- 长期提高速度：这些模式和方法有助于长期提高开发速度。

领域模型的持续更新- 系统设计变化：随着系统设计的变化，更新领域模型至关重要。- 代码重构：与代码重构并行，帮助控制软件系统的复杂性。

领域模型示例图1展示了一个消费者订阅管理系统的域模型示例。[此处应有图示，但由于格式限制，无法展示]

结论领域建模是控制软件开发复杂性的关键工具，能够解决需求和设计意图中的歧义，是敏捷开发中不可或缺的一部分。

领域建模在大规模敏捷开发中的应用

领域建模是一种关键的技术，用于理解和表达问题域的基本方面。在大规模敏捷开发（Scaled Agile Framework, SAFe）中，领域建模不仅支持系统设计，还与多个敏捷实践相结合。

领域建模的基础

领域建模通常通过不同的视图或表示形式来完成，例如鲁棒性图、CRC卡、ORM图等。其中，类图是最为简单和常见的方式，它主要展示了关键实体及其相互关系。

领域建模与系统级需求

有效的领域建模应当在系统级需求的背景下进行。在这个过程中，需求文档中的名词可以成为领域实体的有效候选，而动词可能代表实体的行为和关系。这些实体和行为共同构成了一种通用语言，有助于工程、业务和用户代表之间的沟通，减少误解。

大规模敏捷中的领域建模实践

在SAFe中，领域建模被用于以下方面：

史诗分析：支持对重大解决方案开发计划的分析。- 积压工作细化：在大型解决方案、项目群和团队级别细化待办事项。- 设计工作坊：在不同层次的设计工作坊中使用，以促进团队间的沟通和设计创新。- 完善愿景和路线图：帮助团队更好地理解长期目标和短期里程碑，通常为项目增量做准备。

领域建模的实施者

领域模型通常由系统架构师与其它利益相关者合作开发和不断完善。系统架构师负责定义和沟通共享的技术及架构愿景，确保开发中的系统或解决方案适合其预期目的。

领域模型示例

领域模型可以阐明长篇故事的影响，如图 2 所示，它展示了如何使用领域模型来分析和理解特定功能对现有系统的影响。

结论

领域建模是大规模敏捷开发中不可或缺的一部分，它帮助团队建立共同的理解，促进有效沟通，并为系统设计和开发提供指导。在敏捷软件开发中，领域模型对于理解需求和指导设计至关重要。领域模型与需求紧密相连，相互促进，帮助团队构建对问题域的深入理解。以下是对领域模型及其与需求关系的结构化描述：

领域模型与需求的关系- 领域建模支持需求澄清，帮助团队明确所需功能和行为。- 需求有助于建立和澄清领域模型，确保模型反映了用户的真实需求。

领域模型的变更- 当实施新需求时，领域模型可能会发生变化，如引入新的实体、关系和职责。

积压工作项对领域模型的影响- 史诗：通常引入新的实体，关系和职责。- 特征：可能引入新的实体，通常引入新的关系或职责。- 故事：通常对现有关系和职责进行更改，可能会引入新的职责、值对象或服务接口的更改。- 推动者史诗：影响整个实体、服务和存储库的实现和设计方面。- 启用器功能：更改特定实体/服务的实现/设计，可能引入新的价值对象或改变职责。

领域模型中的通用语言- 领域模型产生的通用语言在敏捷组织中促进了对问题领域、需求和架构的明确共享理解。

领域模型的构建要点- 关系的重要性：模型实体之间的关系对于有效的建模至关重要，它们提供了协作上下文。- 需求定义和设计决策：关系推动了有效的需求定义和设计决策。- 关系的表达：在定义关系时，捕捉实体间的联系比遵循格式协议更为重要。

结论领域模型是敏捷团队不可或缺的工具，它帮助团队深入理解业务需求，指导软件设计，并确保需求的持续澄清和模型的更新。通过领域模型，团队能够构建出更符合用户需求的软件解决方案。

行为驱动开发与通用语言在敏捷组织中的应用

通用语言的重要性与局限性

通用语言在产品开发中扮演着至关重要的角色，它帮助团队成员之间建立共识并促进有效沟通。然而，每个组织都应当意识到其自然存在的局限性。例如，营销材料的语言可能需要使用与通用语言不同的术语，以突出与当前市场趋势或挑战相关的某些特定时间或主观方面。

行为驱动开发中的通用语言

使用行为驱动开发（BDD）的团队在定义人类可读的测试时，会不可避免地在其规范研讨会中使用通用语言。这有助于确保测试的可读性和与业务需求的一致性。

领域模型与系统设计

面向领域的方法

域建模不仅对分析有用，而且通常是系统设计的一个很好的概念模型。域建模是一种关键的设计模式/方法，它假设直接从问题域派生解决方案对象模型，同时保留行为和数据。这种方法提供了一种自然且非常有效的方法来管理软件开发的固有复杂性，尤其在大规模情况下至关重要。

领域驱动设计

领域驱动设计（DDD）是一种系统而详细的设计最佳实践，它基于面向领域的方法。通过DDD，可以更有效地管理软件开发的复杂性，并促进业务和IT之间的协作。

设计方法的比较

图 4 显示了通过不同方法增强软件功能所花费的工作量与复杂性的比较。这包括：

当设计基于领域时的工作量与复杂性。- 当设计基于数据结构或事务脚本时的工作量与复杂性。

结论

在敏捷组织中，通用语言和行为驱动开发是促进团队协作和提高开发效率的重要工具。通过结合领域建模和领域驱动设计，可以更有效地应对软件开发中的复杂性，从而提高产品质量和交付速度。大规模软件解决方案通常面临复杂的领域逻辑。传统的以数据或事务为中心的设计方法，往往导致维护成本高昂。许多组织因此陷入复杂的系统设计，这不仅增加了维护难度，也提高了改进系统的复杂性。尽管在某些特定情境下，这些设计方法可能适用，但大多数情况下，它们是基于个人偏好而非业务需求。面向领域的设计方法，通过建立在领域结构之上，有助于提升系统的可维护性，并支持高度的增量和并发开发。例如，在订阅管理系统中，需求分析和领域建模可能指出，订阅功能是变化的主要来源。考虑到订阅的加入和退出功能，使用桥接模式来隔离变化频繁的区域，并减少系统中的实体数量，是一种合理的设计选择。（参见文献[4]，附录B）

领域建模与系统设计

领域建模是敏捷企业中用于共性-可变性分析（Commonality-Variability Analysis, CVA）的重要工具，它有助于构建有效的系统对象模型。通过领域模型分析，可以有效地识别和组织系统中的共性与可变性，从而提高系统的灵活性和可维护性。CVA方法的详细信息可以在文献[5]的第8章中找到。

非功能性需求对系统设计的影响

非功能性需求（Nonfunctional Requirements, NFRs）通常围绕数据结构或事务脚本构建系统设计，而不是基于领域模型。例如，性能或可扩展性等NFRs可能导致领域逻辑分散在大型SQL脚本或客户端验证脚本中。尽管在某些情况下，使用事务脚本方法可能是合理的，但这应被视为例外而非常规做法。

领域模型的重构

领域建模是一个渐进的过程，随着对系统理解的深入和新领域实体及其关系的实现，领域模型也会相应地进行重构。在领域驱动设计（Domain-Driven Design, DDD）方法中，系统设计和对问题域的理解通常是同步或几乎同步发展的。

领域模型的重要性

领域模型在现实世界的问题域与代码之间提供了至关重要的联系。面向领域的设计方法有助于控制复杂性的增长，并降低维护和增强的成本。领域建模是一个高度协作和可视化的过程，涉及系统架构师、产品经理、利益相关者和开发团队，共同致力于更好地理解问题域和实施解决方案。

总结

领域建模是敏捷企业执行通用语言和基本结构的重要工具，对于分析特性和史诗至关重要。领域模型会随着企业对领域知识的提高和系统功能的增强而不断重构和发展。领域建模是大规模敏捷开发的关键组成部分，它涵盖了多个方面，有助于实现有效的软件开发和维护。

参考文献

Ambler, Scott. Agile Model-Driven Development with UML 2.0. Cambridge University Press, 2004.2. Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley, 2003.3. Fowler, Martin. Patterns of Enterprise Application Architecture. Addison-Wesley, 2002.4. Bain, Scott. Emergent Design: The Evolutionary Nature of Professional Software Development. Addison-Wesley, 2008.5. Shalloway, Alan and James Trott. Design Patterns Explained: A New Perspective on Object-Oriented Design. Addison-Wesley, 2004. 最后更新日期：2021年2月10日本页面上的信息是 © 2010-2024 Scaled Agile, Inc.，受美国和国际版权法的保护。未经版权所有者明确书面许可，不得从本网站复制图像或文本。Scaled Agile Framework 和 SAFe 是 Scaled Agile, Inc. 的注册商标。

文章目录