【问题标题】:Learning DDD and CQRS学习 DDD 和 CQRS
【发布时间】:2019-03-01 09:45:02
【问题描述】:

我是 DDD 和 CQRS 的新手,我正计划构建一个简单的应用程序来提高我的技能。 我打算做的是一个简单的 Taxi Corp 应用程序。

要求:

  1. 客户叫了一辆出租车。
  2. 客户一次只能有一个订单。
  3. 司机挑选订单。
  4. 司机一次只能下一个订单。
  5. 驱动程序转到客户端。
  6. 客户进入驾驶室。
  7. 课程开始。
  8. 课程结束。
  9. 购买客户并支付司机费用

等等。

我可以看到可以有三个聚合:Client、Order 和 Driver。我想将它们拆分为单独的微服务。你认为这是个好主意还是我应该从一个微服务开始?

我目前专注于订购出租车。首先我需要检查客户是否还没有分配课程,稍后我可以创建订单。创建订单后,我需要将其分配给客户。由于在一个请求期间只能更新/创建一个聚合,我想知道如何正确地做到这一点。我读过一些关于流程管理器的东西,我认为它在这种情况下会非常有用。我什至画了一个沟通模式。谁能告诉我我的方法是否正确,并给我一些关于如何走得更远的提示?

Process of creating an order

【问题讨论】:

    标签: domain-driven-design microservices cqrs bounded-contexts


    【解决方案1】:

    你认为这是一个好主意还是我应该从一个微服务开始?

    我建议你参考约翰·高尔的智慧

    人们总是发现一个有效的复杂系统是从一个有效的简单系统演变而来的。从头开始设计的复杂系统永远不会工作,也无法通过修补使其工作。您必须重新开始,从一个工作简单的系统开始。

    不要担心微服务,而是关注消息

    【讨论】:

      【解决方案2】:

      有人说:“如果你的微服务比客户多,那你就错了”。

      如果您真的遵循 CQRS/ES 方法,则生成的系统比传统的 ORM 单体更容易拆分。

      因此,首先关注领域,然后从整体开始。

      【讨论】:

        【解决方案3】:

        即使以错误的方式从微服务设计开始,您也可以更好地了解所需的架构。因为微服务架构设计中的问题很快就会显现出来。

        • 客户端和驱动程序都是系统的用户,并且有一些共同点,因此您可以将它们视为一个域和一个微服务。

        • 考虑一个订单管理器微服务,通过他们的 ID 将客户和司机分配到行程。订单数据库可能包含 trips 表,其中包含两个 id 键,分别代表 driver-Id 和 client-Id 以及一些用于不同状态的列。完成每次行程后,您可以将其从行程表中删除并将其插入存档表中。此外,您可以将它留在那里并每天对表进行分区,以保持数据库的高性能。

        • 考虑使用会计微服务来保存付款和交易。如果您选择将 NoSql 数据库用于其他微服务也没关系,但请务必将 SQL 数据库用于您的事务。

        • 您可能需要另一个用于报告和仪表板的微服务。在新的数据库中镜像其他数据库以进行报告。

        • 您还需要一个 API 网关来将请求路由到微服务或进行身份验证

        您的流程是一组事件。当然,您稍后会扩展系统,并且可能会有一些长时间运行的任务,最好有一个消息代理并使用事件溯源等模式将您的流实现为事件/任务流。

        【讨论】:

          【解决方案4】:

          我可以看到可以有三个聚合:Client、Order 和 Driver。一世 希望将它们拆分为单独的微服务。你认为这是一个 好主意还是我应该从一个微服务开始?

          它们都属于同一个有界上下文。限界上下文可以很好地转换为微服务(参见 Eric Evans 视频:https://www.infoq.com/news/2015/06/dddx-microservices-boundaries)。但是不要从设计微服务开始,你这样做的顺序是错误的。首先设计您的有界上下文,然后在有意义的情况下围绕六边形架构创建一个微服务。

          订单创建后,我需要将其分配给客户。期间 一个请求只能更新/创建一个聚合我想知道如何 正确地做。

          这是为什么您需要在同一个过程中完成所有操作的完美示例。

          但如果您想要使用多个微服务,请考虑最终一致性 (https://en.wikipedia.org/wiki/Eventual_consistency) 并在您的服务之间创建消息驱动的架构。在我看来可能工作量太大,但出于学习目的可能是个好主意。

          【讨论】:

            猜你喜欢
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 2018-08-12
            • 2014-10-21
            • 1970-01-01
            • 1970-01-01
            • 2018-09-05
            • 2014-10-23
            相关资源
            最近更新 更多