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