4

Our client has a requirement to re-design from scratch a product in an Enterprise Architecture Business Domain. The product has an ability to model business processes, information, technology, infrastructure, data etc. for the entire organization of the end user with the help of standard E.A. Framework methods & tools like BPM/N, TOGAF, ArchiMate, etc.

There are many abstract (meta) modelling concepts which enables the product to also integrate with multiple third-party systems e.g. ERP, CRM, Project Management, Financial Management & Service Delivery systems of the end-customers for data synchronization purpose.

The question - Is Domain-Driven Design a right fit for modeling the core domain of this kind of product?

4

2 回答 2

4

我推荐阅读 Eric Evans 的“领域驱动设计”和 Vaughn Vernon 的“实施领域驱动设计”。首先要意识到的是，不要建立一个统治他们所有人的大模型。DDD 是关于域（其中一个是核心域）和子域。它是关于可以以书中描述的各种方式连接的有界上下文。所以基本上你最终会得到很多带有看似冗余数据的自治子系统，它们以松散耦合的方式相互通信，并通过松散耦合的通信同步它们的部分数据。许多总体约束只会最终保持一致，系统、流程和用户必须容忍这一点。

因此，在您描述的复杂情况下，我认为是的。DDD 非常适合多个系统的多个核心域。但是可以随意在纯粹以数据为中心的子系统中使用更简单的方法。

于 2015-03-09T13:37:58.487 回答
4

企业架构项目将为您的业务提供一个分层模型……它将精确化您领域的所有组件化部分：参与者、部门、服务、功能……如果您的目标是在领域上调整解决方案（如我假设），我认为领域驱动开发非常适合您想要实现的目标。基本上，EA 可以向您展示您的解决方案应该是什么样子。由于 DDD 完全是关于“专业化”，而不是“重用”或“泛化”，因此您应该注意不要依赖可能破坏您的有界上下文的遗留服务（例如，在 DDD 中，业务规则实现应该保留在 BC它们提供服务，而不是分散在外部依赖项的整个解决方案中......）。EA 是定义通用语言的绝佳工具，有界上下文边界。DDD 擅长设计服务边界。EA 将提供有助于您设计 BC 的战略工具。由于 DDD、SOA、EA 共享许多共同的第一公民原则，它们将非常适合。

我的投稿来晚了，你有什么经验可以分享给我们吗？

于 2015-05-04T18:20:00.873 回答