我们的应用程序中有一个单一的Web API层，有一百个端点。我试图使用Azure Service Fabric将其分解为微服务。当我们将它们分解为多个服务时，我们可能最终会有重复的代码。
示例：假设我们有一个帐户服务来创建帐户。并且有一种付款服务可以将付款应用于交易。在这种情况下，两个服务都需要Customer类/域。账户服务可能需要一个详尽的客户提供完整的详细信息，但付款可能需要一个轻量级的客户。
问题是我们需要复制几个域实体，还有其他这样的层？这不会产生更多的维护问题吗？
如果我们不这样做，我们最终会复制代码并创建不同的服务，一个单一的服务就是现有的Web API。
有什么想法吗？
2，我们有一些今天提到交易的情况。如果我们将它们分开，是否有任何好的设计来记录故障和回滚而不必过多地维护交易？
将一个整体打造成适当的微服务，并为你的领域设置适当的边界，这当然更像是一门艺术，而不是一门科学。承担此类任务的先决条件是彻底了解您的域名及其内部的互动，您将无法在第一时间做到正确。 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微服务，告诉它更新其账单地址。 Payments除了单个API调用之外，不需要知道如何更新Customer的帐单地址;任何域逻辑，验证，域事件触发等......需要在该操作中发生的一部分包含在Customer微服务中。
关于你的第二个问题：在分布式架构中，原子事务变得更加复杂/困难。对佐贺图案做一些阅读：https://blog.couchbase.com/saga-pattern-implement-business-transactions-using-microservices-part/。此外，Jimmy Bogard目前正处于一个名为Life Beyond Distributed Transactions: An Apostate's Implementation的博客系列中，可能会提供一些很好的见解。
希望这可以帮助！