小机灵鬼|干货速来！透彻剖析微服务架构设计模式，深入开发Java有奇效( 七 ) 什么是微服务模式随着网络基础设施的高

一种解决方案是将 Order 类打包到库中并创建一个中央 Order 数据库。处理订单的所有服务都使用此库并访问访问数据库。这种方法的问题在于它违反了微服务架构的一个关键原则，并导致我们特别不愿意看到的紧耦合。例如，对 Order 模式的任何更改都要求其他开发团队同步更新和重新编译他们的代码。
另一种解决方案是将 Order 数据库封装在 Order Service 中，该服务由其他服务调用以检索和更新订单。该设计的问题在于这样的一个 Order Service 将成为一个纯数据服务，成为包含很少或没有业务逻辑的贫血领域模型（anemic domain model）。这两种解决方案都没有吸引力，但幸运的是， DDD 提供了一个好的解决方案。
更好的方法是应用 DDD 并将每个服务视为具有自己的领域模型的单独子域。这意味着FTGO 应用程序中与订单有关的每个服务都有自己的领域模型及其对应的 Order 类的版本。 Delivery Service 是多领域模型的一个很好的例子。如图 2-11 所示为 Order ，它非常简单：取餐地址、取餐时间、送餐地址和送餐时间。此外， Delivery Service 使用更合适的 Delivery 名称，而不是称之为 Order 。 Delivery Service 对订单的任何其他属性不感兴趣
Kitchen Service 有一个更简单的订单视图。它的 Order 版本就是一个 Ticket（后厨工单）。如图所示， Ticket 只包含 status、requestedDeliveryTime、prepareByTime 以及告诉餐馆准备的订单项列表。它不关心消费者、付款、交付等这些与它无关的事情
Order Service 具有最复杂的订单视图，如图所示。即使它有相当多的字段和方法，它仍然比原始版本的那个 Order 上帝类简单得多。
每个领域模型中的 Order 类表示同一 Order 业务实体的不同方面。 FTGO 应用程序必须维持不同服务中这些不同对象之间的一致性。例如，一旦 Order Service 授权消费者的信用卡，它必须触发在 Kitchen Service 中创建 Ticket 。同样，如果 Kitchen Service 拒绝订单，则必须在 Order Service 中取消订单，并且为客户退款。我们通常会用用分布式事务去处理这些问题，这又是微服务架构的另一个问题了。
以上就是小编整理的微服务架构设计模式，有哪里不准确的，请各位朋友多多指出，小编和大家一起共同学习进步~~~
【小机灵鬼|干货速来！透彻剖析微服务架构设计模式，深入开发Java有奇效】喜欢请点赞评论转发，关注小编，后续小编会带来更丰富的学习内容更新~~~