我们的应用程序中具有一个整体Web API层，具有一百个端点。我正在尝试使用Azure Service Fabric将其分解为微服务。 当我们将它们分成多个服务时，我们可能最终会得到重复的代码。
示例：假设我们有一个帐户服务可以创建一个帐户。还有一种付款服务，可将付款应用于交易。 在这种情况下，两个服务都需要Customer类/域。帐户服务可能需要详尽无遗的详尽客户，但付款可能需要轻巧的客户。
问题是我们是否需要复制几个域实体以及其他类似的层？这不会带来更多维护问题吗？
如果不这样做，我们最终将复制代码并创建不同的服务，那么一个单一的服务就是现有的Web API。
对此有何想法？
第二，今天有些情况涉及交易。如果我们将它们分开，是否有任何好的设计来记录故障和回滚而又不花太多精力维护事务？
答案 0 :(得分：1)
在您的域的适当边界范围内，将整体变成适当的微服务无疑是一门艺术，而不是一门科学。进行此类任务的前提条件是对域及其内部的相互作用有透彻的了解，而您不会在第一时间就将其正确。 Evans在其关于域驱动设计的书中提出的观点之一是，对于任何足够复杂的域，域模型都会不断发展，因为您对域的理解正在不断发展。明天您会比今天更好。就是说，当您对“足够好”的理解并愿意适应/发展模型时，不要害怕开始。
我不知道您的域，但是在我看来，您需要首先弄清楚bounded context Customer主要属于哪个领域。是的，您希望最大程度地减少域逻辑的重复，尽管它可能无法完全和整洁地集成到单个服务中，但要使您使一个服务承担访问，持久化，操作，验证和确保完整性的主要责任。 Customer，您的生活就会更好。
从您的问题中，我看到两种可能性：
Account Services的边界上下文是Customer的主要利益相关者，并且Customer与其他Account Services实体和服务有着重要的联系。孤立地在Customer周围划清界限很难。在这种情况下，Customer属于Account Services有界上下文。Customer是一个足够独立的概念，值得拥有自己的微服务。 Customer可以单独使用。在这种情况下，Customer属于其自己的有界上下文。无论哪种情况，都应格外小心，以确保特定于Customer的域逻辑在强大边界之后的Customer微服务中保持集中。其他服务可能会使用Customer，或者可能是轻量级的（甚至是只读的）CustomerView，但是它们之间的交互应尽可能地通过Customer服务。
在您的问题中，您指出Payments有界上下文将需要访问Customer，但可能只需要轻量级版本。它应与Customer服务进行通信以获取该轻量对象。例如，如果在付款处理期间您需要更新Customer的账单地址，则Payments应调用Customer微服务，告知其更新账单地址。除单个API调用外，Payments不需要了解有关如何来更新Customer的账单地址的任何信息； Customer微服务中包含该操作的一部分需要发生的任何域逻辑，验证，域事件的触发等。
关于您的第二个问题：的确，原子事务在分布式体系结构中变得更加复杂/困难。阅读Saga模式：https://blog.couchbase.com/saga-pattern-implement-business-transactions-using-microservices-part/。此外，吉米·博加德（Jimmy Bogard）目前正在参与一个名为 Life Beyond Distributed Transactions: An Apostate's Implementation可能会提供一些很好的见识。
希望这会有所帮助！