InfoQ如何基于 DDD 构建微服务?( 六 )


如果跨平台都遵循这种模式 , 则可能会导致各种域服务之间形成复杂的依赖关系网 , 这都是因为这些服务迎合了调用者特定的访问模式 。
专门服务于前端的后端(BFFs)
一种减轻这种风险的方法是让调用者团队管理各种域服务之间的编排 。 毕竟 , 调用方更了解访问模式 , 并且可以完全控制对这些模式的任何更改 。 这种方法将域服务从表示层解耦出来 , 让它们专注于核心业务流程 。 但是 , 如果 Web 和移动应用程序开始直接调用不同的服务 , 而不是从单体中调用一个复合 API , 这可能会给这些应用程序带来性能开销——在较低带宽的网络上进行多次调用 , 处理和合并来自不同 API 的数据 , 等等 。
相反 , 可以使用另一种称为用于前端的后端模式(Backend for Front-ends) 。 在这种设计模式中 , 由消费者创建和管理的后端服务 , 在本例中是 Web 和移动团队 , 它负责对多个域服务进行集成 , 纯粹是为了向客户提供前端体验 。 Web 和移动团队现在可以根据它们所需要的用例来设计数据契约 。 它们甚至可以使用 GraphQL 而不是 REST API 来灵活地查询并获取所需的内容 。 需要注意的是 , 该服务是由消费者团队拥有和维护的 , 而不是提供域服务的团队 。 前端团队现在可以根据它们的需求进行优化——移动应用程序可以请求更小的有效负载 , 减少来自移动应用程序的会话次数 , 等等 。 下面是修订后的业务流程图 。 BFF 服务现在为其用例调用“订单”和“退款”域服务 。
InfoQ如何基于 DDD 构建微服务?
本文插图
图 9:用于前端的后端
尽早构建 BFF 服务也很有用 , 这样可以避免从单体系统中分解出过多的服务 。 否则 , 要么域服务必须支持域间编排 , 要么 Web 和移动应用程序必须直接从前端调用多个服务 。 这两个选项都会导致性能开销、一次性工作以及团队之间缺乏自治 。
相关阅读:
https://www.walmart.com/ip/Domain-Driven-Design-Tackling-Complexity-in-the-Heart-of-Software-Hardcover-9780321125217/2222375
https://www.walmart.com/ip/Implementing-Domain-Driven-Design-Hardcover-9780321834577/21124187
https://martinfowler.com/articles/microservices.html
https://www.walmart.com/ip/Building-Microservices-Designing-Fine-Grained-Systems-9781491950357/40970629
https://www.youtube.com/watch?v=1i6QYvYhlYQ
https://www.thoughtworks.com/insights/blog/bff-soundcloud
https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
参考阅读:
https://medium.com/walmartlabs/building-domain-driven-microservices-af688aa1b1b8
InfoQ 读者交流群上线啦!各位小伙伴可以扫描下方二维码 , 添加 InfoQ 小助手 , 回复关键字“ 进群 ”申请入群 。 大家可以和 InfoQ 读者一起畅所欲言 , 和编辑们零距离接触 , 超值的技术礼包等你领取, 还有超值活动等你参加 , 快来加入我们吧!
点个在看少个 bug