将大型复杂系统模块化为更小、更易于管理的部分是很好的最佳实践，不仅可以降低每个部分的认知负担，还可以实现团队独立性和操作弹性。
棘手的一点是如何划定边界？为整个系统建立一个稳定和可持续的结构。基于有界上下文的领域驱动设计是一种方法，其中是使用领域语言作为指导，另一种方法是从业务模型定义的能力中汲取灵感，以找到领域中的自然接缝。
“业务能力是企业为实现特定目的或结果而可能拥有或交换的特定能力。” ——乌尔里希·霍曼
什么是业务能力
业务能力模型在企业架构中经常用作以整体方式描述公司的一种方式，代表独立于结构、流程、人员或资源，如 IT 系统、建筑、材料、硬件、工具等。一切都包括在内，每个螺母和螺栓；没有任何东西属于模型之外，它的前提是公司的由外而内的视角，因为它严格描述了公司的能力——它的赋能能力。
业务能力建模与 公司基于资源的视图相关 ，通常被视为对它的扩展，因为它也支持 经典价值链之外的其他 价值配置，如 价值网络 和 价值商店。
这种类型的建模听起来可能是学术性的，而且是只有企业和企业架构师才关心的，但它是非常实际和广泛适用的。
简单地说，能力是企业认为自己具备的能力，即对内部和外部各方而言的能力。
让这个概念有点难以理解的是，它们本质上描述了公司“做什么”，而不是 “如何做”。
它是业务现实的抽象，将它们与经典的业务流程建模区分开来，后者通常侧重于 "如何"完成工作。这种抽象性还使得能力本质上比其他方法更稳定，因为它们在实现时不会改变，比如使用软件的自动化。他们改变的唯一原因是公司的战略调整，比如决定转向、扩展或搬出某个业务领域。
这种严格抽象的业务视图为其支持组件（无论是角色（人员）、流程、信息和资源）提供了一个显式的业务上下文。
这个优势的一个有趣的方面是能力需要相当独立，这意味着它必须能够以相对独立的方式提供这种能力。
此外，这些能力自然是分层的和可分解的，这意味着一个顶级能力，例如销售，将包含许多能力，这些能力又将包含另一组。级别的数量根据企业的规模和复杂性而有所不同，但通常有3-4个级别。
尽管业务能力似乎只有业务和企业架构师关心，但它们的用途远不止战略规划和文档，其中一些甚至可能与开发人员和软件架构师相关。尤其是它们固有的独立性和逻辑边界，非常符合 SOA/微服务的自主性和显式边界原则，以及领域驱动设计中的有界上下文概念。
即使手头没有定义的业务能力模型，该概念也可用于将这些服务识别为启发式。如果您可以将建议的边界与可表征为业务能力的事物相匹配，那么您可能会获得良好的自治服务。
业务能力如此通用的原因在于它们的描述性，它们很好地定义了问题空间，而对解决方案空间一无所知。它们是许多更详细建模的良好基础，从业务角度来看是稳定的，并且只有在业务本身发生变化时才会发生变化。
领域建模
通常，这种建模是协作完成的，让所有具有正确业务知识的人都进入同一个房间。这不是少数人孤立地独自做的事情，但有时从零开始，在邀请忙碌的人在会议上为其贡献之前，先建立一个“稻草”模型，这可能是有利的。
在邀请人们参加研讨会之前，务必明确提出期望。无论目标是定义整个企业的全局图，还是详细说明较低级别的能力，都表明需要参与的人员。对于顶层映射，需要来自整个企业的高级业务主管、企业架构师和业务架构师，而对于特定能力的详细描述，则需要对该部分有深入了解的人员，如产品经理、系统问题专家和软件架构师。
尽管尝试创建一个完整的能力图似乎是明智的，从层次结构的顶层一直延伸到较低的层次，但这种努力很可能会掩盖其好处。因此，根据手头的具体目标调整计划，无论是创建用于业务建模的顶层模型，还是模块化属于这些顶层能力之一的软件整体。
目标是捕获和记录代表企业现在做什么以及它对未来的期望的能力。在大多数公司中，某种业务模型和业务架构已经存在并且应该作为输入带到研讨会，无论是价值链分析、业务流程还是业务计划。即使是现有的组织结构图、核心业务实体的列表也可以获得灵感。对于某些行业，甚至存在公开可用的参考模型，可以从中受益。
其他出色的建模和协作技术，如事件风暴、用户故事映射、领域故事讲述、业务模型画布、示例映射、影响映射、沃德利映射等等，所有这些技术均由行业专家编写拥有丰富的工具使用经验。
