我们的客户需要从头开始重新设计企业架构业务领域中的产品。该产品能够在标准 E.A. 的帮助下为最终用户的整个组织建模业务流程、信息、技术、基础设施、数据等。 BPM/N、TOGAF、ArchiMate等框架方法和工具。
有许多抽象（元）建模概念使产品还可以与多个第三方系统集成，例如最终客户的 ERP、CRM、项目管理、财务管理和服务交付系统，用于数据同步。
问题 - 领域驱动设计是否适合对此类产品的核心领域进行建模？
【问题讨论】：
标签： domain-driven-design product-development
我推荐阅读 Eric Evans 的“领域驱动设计”和 Vaughn Vernon 的“实施领域驱动设计”这两本书。首先要意识到的是，不要建立一个统治他们所有人的大模型。 DDD 是关于域（其中一个是核心域）和子域。它是关于可以以书中描述的各种方式连接的有界上下文。所以基本上你最终会得到很多带有看似冗余数据的自治子系统，它们以松散耦合的方式相互通信，并通过松散耦合的通信同步它们的部分数据。许多总体约束只会最终保持一致，系统、流程和用户必须容忍这一点。
因此，在您描述的复杂情况下，我认为是的。 DDD 非常适合多个系统的多个核心域。但您可以随意在纯粹以数据为中心的子系统中使用更简单的方法。
【讨论】：
企业架构项目将为您的业务提供一个分层模型...它将精确化您领域的所有组件化部分：参与者、部门、服务、功能...如果您的目标是使解决方案与领域保持一致（我想），我认为领域驱动开发非常适合您想要实现的目标。基本上，EA 可以向您展示您的解决方案应该是什么样子。由于 DDD 完全是关于“专业化”，而不是“重用”或“泛化”，因此您应该注意不要依赖可能破坏您的有界上下文的遗留服务（例如，在 DDD 中，业务规则实现应该保留在 BC它们提供服务，而不是分散在外部依赖项的整个解决方案中......）。 EA 是定义通用语言、限界上下文边界的绝佳工具。 DDD 擅长设计服务边界。 EA 将提供有助于您设计 BC 的战略工具。由于 DDD、SOA、EA 共享许多共同的第一公民原则，它们将非常适合。
我的投稿来晚了，你有什么经验可以分享给我们吗？
【讨论】：