转载

根据业务能力实现DDD建模 - trond

将大型复杂系统模块化为更小和更易于管理的部分是一种最佳实践，这不仅是为了降低每个部分的认知负担，而且还可以降低团队的独立性和运营弹性。棘手的一点是如何划定边界，使整个系统稳定而可持续。

带有边界的上下文是领域驱动设计的一种方法，业务领域的语言用作指导，还有另一种方法是从业务模型定义的功能中汲取灵感，以找到领域中的自然边界。

“业务能力是企业为实现特定目的或成果而拥有或交换的特定能力。” –乌尔里希·霍曼（Ulrich Homann）

这是Leanpub上免费的 Visual Collaboration Tools 书籍中发布的有关业务能力建模的章节的精简版。

什么是业务能力

业务能力模型经常用于企业体系结构中，以一种整体描述公司的方式，代表组织的业务模型，但与结构，流程，人员或资源（例如IT系统，建筑物，材料，硬件，工具，知识等）无关，它严格描述了公司的职能。

业务能力建模与公司基于资源的视图有关，通常被视为对它的扩展，因为它还支持经典价值链之外的其他价值配置，例如价值网络和价值商店。

这种类型的建模听起来听起来像是学术性的，只有企业和企业架构师才关心，但它是切实的并且广泛适用。

简而言之，这些功能是企业内部和外部各方都认为自己具有的职能。

它是业务现实的一种抽象，使它们与经典业务流程建模（通常专注于如何完成事情）区分开。这种抽象性也使这些功能固有地比其他方法更稳定，因为它们的实现在执行时不会改变，例如人工执行和使用软件自动化时都不会改变。他们发生改变的唯一原因是公司的战略调整，例如决策进入、扩展或移出某些业务领域。

这种严格而抽象的业务视图赋予其使能组件，包括角色（人员），流程，信息和资源，以及明确的业务上下文。

有趣的是，功能必须相当独立，这意味着它必须能够以相对无关的方式实现自己的功能。此外，这些功能自然是分层的和可分解的，这意味着一个顶级功能（例如Sales）将包含许多功能，而这些功能又将包含另一组功能。级别的数量根据企业的规模和复杂性而有所不同，但是通常有3-4个级别。

尽管似乎业务功能只是业务和企业架构师所关心的，但它们可以用于的范围远远超过战略规划和文档编制，其中某些功能甚至与开发人员和软件架构师有关。特别是它们的固有独立性和逻辑边界非常适合SOA /微服务的自治性和显式边界原则，以及域驱动设计中的有界上下文概念。

即使手头没有定义的业务能力模型，该概念也可以用于将一些服务作为启发入口。如果您可以将建议的边界与可以描述为业务能力的特征相匹配，则可能会获得良好的自治服务。

使业务功能如此通用的原因在于其描述性，它们很好地定义了问题空间，而对解决方案空间无关。它们是进行更多详细建模的良好基础，从业务角度来看是稳定的，并且仅在业务本身发生变化时才发生变化。

如何建立模型

通常，这种建模是协作完成的，将具有适当业务知识的所有人员都放在同一个房间中。这不是少数人孤立地做的事情，但有时在从头开始时有人邀请一个忙碌的人在车间里为它做模型之前，先建立一个稻草模型是有好处的。

在邀请人们参加研讨会之前，明确期望是非常重要的。目标是定义整个企业的全景图还是要详细说明较低级别的功能，都表明需要谁参与。对于顶层映射，需要企业中的高级业务主管，企业架构师和业务架构师，而对于特定功能的详细说明，则需要对这一部分有深入了解的人员，例如产品经理，系统问题专家和软件建筑师。尽管尝试创建一个完整的功能图似乎很明智，从头到尾一直到层次结构的下层，但这种努力很可能使收益蒙上阴影。因此，应根据当前的具体目标调整主动权，

目的是捕获和记录代表企业现在所做的事情以及对未来的期望的能力。在大多数公司中，已经存在某种业务模型和业务架构，应该将其作为输入，包括价值链分析，业务流程和业务计划。即使是现有的组织结构图，对于灵感以及核心业务实体列表也可能很有趣。对于某些行业，甚至存在可以参考的公开可用参考模型。

要了解有关业务能力建模的更多信息，以及如何在实践中进行操作，以及如何举办研讨会以及如何定义和记录结果的技巧，请查阅Leanpub上免费的 Visual Collaboration Tools 书籍。在这里，您还可以了解有关许多其他出色的建模和协作技术的信息，例如事件风暴，用户故事映射，域故事讲述，业务模型画布，示例映射，影响映射，Wardley映射等等，所有这些都是由行业专家撰写的有很多使用工具的经验。通过支付少量费用，您还可以为良好的事业做出贡献，这是一项技术多元化计划。

原文 https://www.jdon.com/54481

正文到此结束