山姆·纽曼（Sam Newman）在他的《建筑微服务》一书中指出
服务之间过多耦合的弊端远不如代码重复所引起的问题
我只是不了解服务之间的共享代码是多么邪恶。作者是否表示如果需要共享库，则服务边界本身设计不良，还是真的意味着在出现常见业务逻辑依赖性时我应该复制代码？我看不出能解决什么。
假设我有两个服务共有的实体共享库。两个服务的公共域对象可能有异味，但是另一个服务是用于调整那些实体状态的GUI，另一个是用于其他服务轮询其状态的接口。相同的域，不同的功能。
现在，如果共享知识发生了变化，无论通用代码是外部依赖项还是跨服务重复，我都必须重建和部署这两个服务。通常，这取决于业务逻辑的同一条，涉及两种服务的所有情况。在这种情况下，我只会看到重复代码的危害，从而降低了系统的凝聚力。
当然，在共享库的情况下，与共享知识区分开可能会引起头痛，但是即使这样，也可以通过继承，组合和抽象的巧妙使用来解决。
那么，山姆所说的代码复制比通过共享库进行过多耦合要好吗？
architecture interface distributed-computing shared-libraries microservices