7

我有点困惑。我在一家年轻的银行公司工作，我们决定实施 DDD 架构来打破复杂性。

所以，这是我的问题（它遵循团队中某人提出的设计建议）。假设我们有 3 个不同的域。D1、D2、D3，公开域（Web）服务。每个域都操作依赖于相同表的强类型业务实体。在这些领域之前，我们希望微服务以集中的方式保证表中持久化的数据是一致的。D1、D2 和 D3 要求微服务将符合特定规则的数据持久化。我们希望微服务充当表的 CRUD 代理。微服务为 D1、D2 和 D3 域提供特定的 DTO，将表混淆为 D1、D2、D3。

这种方法听起来不错吗？您会考虑在 DDD 架构中使用微服务来管理 1+ 个域的 CRUD 和数据一致性吗？使用微服务“CRUDing”和验证数据是否会破坏有界上下文？如果有的话，在 DDD 架构中处理微服务的最佳实践是什么？

非常感谢您的贡献，

[编辑]

以下文章帮助我完善了我的想法：http ://martinfowler.com/bliki/MicroservicePremium.html

微服务在单体系统无法维护的复杂情况下很有用。它们不是前期设计实施的良好候选者。另一方面，DDD 试图在项目一开始就解决复杂性。成功的 DDD 不应该满足微服务实现。

4

2 回答 2

13

诸如验证、计算和持久性 (CRUD) 之类的东西都是函数，而不是服务。通过将这些任务集中到一项服务，您将所有其他服务紧密耦合到它，并失去了 SOA 的主要优势。使您的服务松散耦合，同时保持高内聚应该是您的主要目标。我觉得这种设计违反了这一点。

您希望将服务设计为相关业务功能的垂直切片，而不是集中的通用服务和层。服务应该由部署在整个企业中的组件组成，从数据库一直到 UI。此外，如果不切实际，每个服务都应该有自己的数据库或至少架构。一旦您的服务共享一个数据库，您就会再次变得紧密耦合。

最后一点，如果您的一项服务需要执行简单的 CRUD 插入，那么它应该就是这样。无需先将其映射到域模型。为具有需要强制执行的真实不变量的业务流程保存 DDD。它不必是全有或全无的方法。使用对每个用例都有意义的工具。

于 2015-04-15T02:53:31.303 回答
6

微服务不应该“打破”有界上下文，它们是互补的，因为微服务和 BC 边界之间存在自然关联。

我们希望微服务以集中的方式保证表中持久化的数据是一致的

微服务不是为了立面目的。它们都是关于去中心化，而不是中心化。它们是围绕业务能力组织的模块化单元。它们通常充当域前面的有界上下文的网关，而不是域后面的持久存储的代理。

似乎您正试图对您的问题应用错误的解决方案——使用微服务作为以数据为中心的单体的汇聚点，这违背了他们的全部目的。

也许您应该详细说明“保证数据持久化是一致的”和“持久化数据符合特定规则”的意思。它可能只是在持久层或不是微服务的服务中实现。

于 2015-04-15T08:57:54.113 回答