我有点困惑。我在一家年轻的银行公司工作，我们决定实施DDD架构来打破复杂性。
所以，这是我的问题（它遵循团队中某人的设计建议）。假设我们有3个不同的域名。 D1，D2，D3，暴露域（网络）服务。每个域操作依赖于相同表的强类型业务实体。在这些域之前，我们希望微服务保证表中持久存储的数据是集中的。 D1，D2和D3要求微服务保持符合特定规则的数据。我们希望微服务充当表的CRUD代理。微服务为D1，D2和D3域提供特定的DTO，将表混淆为D1，D2，D3。
这种方法听起来不错吗？您是否会考虑在DDD架构中使用微服务来管理1+域的CRUD和数据一致性？使用微服务“CRUDing”和验证数据是否打破了有限的上下文？在DDD架构中处理微服务的最佳实践是什么？
非常感谢您的贡献，
[编辑]
以下文章帮助我改进了我的想法：http://martinfowler.com/bliki/MicroservicePremium.html
微服务在单片系统无法维护的复杂情况下非常有用。它们不适合前期设计实施。另一方面，DDD试图在项目一开始就解决复杂问题。成功的DDD不应该满足微服务的实现。
答案 0 :(得分：13)
验证，计算和持久性（CRUD）之类的东西都是功能而不是服务。通过将这些任务集中到一个服务，您将所有其他服务紧密地耦合到它，并失去SOA的主要优势。让您的服务松散耦合，同时保持高凝聚力应该是您的首要目标。我觉得这个设计违反了这一点。
您希望将服务设计为相关业务功能的垂直切片，而不是集中式通用服务和层。服务应该包含从整个企业部署的数据库，从数据库一直到UI。此外，每个服务都应该拥有自己的数据库，或者至少是架构，如果不实用的话。只要您拥有共享数据库的服务，您就会再次紧密耦合。
最后一点，如果你的一个服务需要做一个简单的CRUD插入，那就应该是这样。无需先将其映射到域模型。将DDD保存为具有需要强制实际不变量的业务流程。它不一定是全有或全无的方法。使用对每个用例都有意义的工具。
答案 1 :(得分：6)
微服务不应该“打破”有界上下文，它们是互补的，因为它有natural correlation between microservice and BC boundaries。
我们希望微服务能够保证表中的数据持续存在 以集中的方式保持一致
微服务不在此用于说明目的。它们都是关于 de 集中化，而不是集中化。它们是围绕业务能力组织的模块化单元。它们通常充当绑定上下文的网关，在域之前，而不是代理域后面的持久存储。
您似乎正试图将错误的解决方案应用于您的问题 - 使用微服务作为以数据为中心的整体的汇聚点，这会破坏其整体目的。
也许您应该详细说明“保持数据保持一致”和“保持数据符合特定规则”的含义。它可能只是在持久层或非微服务的服务中实现。