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