这是一个具有现实意义的抽象问题。
我有两个微服务；我们称它们为CreditCardsService和SubscriptionsService。
我还有一个应该使用SubscriptionsService的SPA，以便客户可以订阅。为此，SubscriptionsService具有一个端点，您可以在其中使用POST订阅模型来创建订阅，并且该模型中的creditCardId指向应为该订阅支付的信用卡。有一些业务规则规定您是否可以使用该信用卡进行订阅（有效期超过12个月，这是VISA等）。这些特定的业务规则与SubscriptionsService
问题是在SPA上工作的团队希望在/CreditCards中有一个SubscriptonsService端点，该端点返回可以在订阅模型中使用的用户的所有有效信用卡。他们不想在SPA中实现与SubscriptionsService本身相同的业务验证规则。
在我看来，这似乎违反了微服务设计至关重要的SOLID原则。特别是关注点分离。我也问自己，这将设定什么先例？我们是否必须将/CreditCards终结点添加到OrdersService或可能使用creditCardId作为其模型属性的任何其他服务？
因此，主要问题是：设计此方法的最佳方法是什么？是否应该在前端和后端之间复制业务验证逻辑？是否应将此新端点添加到SubscriptionsService？我们应该尝试简化业务逻辑吗？
最佳答案
在微服务和DDD中，如果订阅服务的数据与订阅的受限上下文有关，则订阅服务应具有信用卡终结点。
信用卡终结点提供的数据模型可能与您在信用卡服务本身中发现的数据模型稍有不同，因为在订阅的上下文中，信用卡的外观或行为可能有所不同。订阅服务可能会有一个信用卡表或后备存储，以支持存储其自己的信用卡架构并引用一些真实来源以使数据保持良好状态（例如，有关公交车卡事件的消息或其他信息）机制）。
这实现了三件事：首先，如果卡掉了一段时间，订阅服务将不会被完全淘汰，它可以引用自己的表并继续工作。其次，您的域代码将更加集中，因为它只需要处理对解决当前问题真正重要的信用卡属性。最后，如果您的卡存储甚至可以具有在存储中计算和实现的额外的特定于域的属性。
强制性福勒链接：Bounded Context Pattern
关于domain-driven-design - 前端与ddd微服务后端的业务逻辑重复，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/54557354/