小机灵鬼|干货速来！透彻剖析微服务架构设计模式，深入开发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有奇效】喜欢请点赞评论转发 ， 关注小编 ， 后续小编会带来更丰富的学习内容更新~~~
推荐阅读
- 操作系统|干货分享：优麒麟系统上的硬盘读写性能测试
- 北京|北京晚高峰拥堵指数突破年度极值！司机灵魂拷问：我干嘛要开车？
- 尼康|索尼官微抖机灵“翻车”：国际空间站宇航员一直用尼康相机
- 比特币|2021年巴菲特股东大会15条干货出炉：承认卖错股票、给比特币定调
- 任豪|任豪发文回应言论争议 抖机灵发言令人费解 日本人看了都一脸懵
- 干货｜全球上市的十大PD-1/L1用药信息大盘点！2020版
- 超多干货！新能源的“蔚来”疾驰而至 固态电池凭什么这么能打？
- 充满正能量的人生哲理语录，精辟透彻，让人幡然醒悟！
- 马未都是如何看待王刚在鉴宝现场砸藏品的他的回答很透彻
- 板绘鼻子详细画法干货详解！让人感到惊艳的鼻子绘製方法！