微服务间共享库为何有害？对Sam Newman观点的困惑

Great question—this is one of the most common sticking points when teams first adopt microservices, so you’re not alone in scratching your head over this! Let’s break down Sam Newman’s argument and your specific questions.

核心观点：耦合的代价远大于代码重复 #

服务间过度耦合的危害远大于代码重复带来的问题。

Sam’s point boils down to this: microservices live or die by their ability to evolve independently. When you share code between services—especially business logic code—you create a hidden dependency that undermines this independence. Here’s why that’s risky:

• Forced synchronized updates: If two services rely on the same shared library (say, order-processing-utils), any change to that library requires both services to be updated, tested, and deployed at the same time. Even if one service doesn’t need the new feature, it still has to upgrade to stay compatible. This turns independent deployments into coordinated releases, which is exactly what microservices are supposed to avoid.
• Blurred service boundaries: Shared code often leads to shared assumptions about business rules. Over time, services start relying on more and more shared logic, slowly merging back into a "distributed monolith" where a change in one service can break others in unexpected ways.

你的两个关键疑问 #

1. 出现共享库需求是不是说明服务边界设计不合理？ #

Most of the time, yes. If you find yourself wanting to share business logic between two services, it’s a red flag that your service boundaries might be misaligned. For example:

• If both your order service and payment service need to validate user addresses, maybe address validation should be a standalone service (with its own API) instead of a shared library.
• Or, maybe you’ve split a single cohesive business domain into two services—like splitting "user management" into two services that both need access to the same user logic. In that case, rethinking the boundary to keep related logic together makes more sense than sharing code.

2. 通用业务逻辑真的要重复编写吗？ #

Not exactly—you just need to avoid sharing code and instead share contracts or services:

• Use standalone services for shared business logic: If multiple services need the same business capability (like calculating taxes or verifying coupons), build a dedicated service for that functionality. Other services call its API instead of importing a library. This way, each service only depends on the API contract, not the underlying code.
• It’s okay to share non-business code: Pure utility code (like date formatting, string helpers, or logging utilities) is safe to share across services. These don’t tie to business rules, so changes here are unlikely to cause cascading issues.
• Accept limited code repetition when necessary: If a business rule is truly specific to two separate services (e.g., order service calculates shipping costs differently than a returns service), duplicating that code is acceptable. The cost of maintaining two copies is far lower than the risk of coupling the two services together.

举个实际例子 #

Let’s say you’re building an e-commerce platform, and both your order service and inventory service need to check if a product is in stock.

• Bad approach: Share a stock-checker library between both services. When you update the stock-checking logic (e.g., adding backorder support), both services must be updated and deployed together. If the inventory service’s deployment fails, the order service can’t launch its new feature either.
• Good approach: Build a dedicated inventory service with an API endpoint like GET /products/{id}/stock-status. The order service calls this endpoint instead of using a shared library. Now, you can update the inventory service’s logic independently without touching the order service, and vice versa.

最终总结 #

Code duplication is a minor inconvenience—you can always refactor it later if needed. But service coupling is a long-term, systemic problem that locks you into inflexible releases and makes it impossible to scale or evolve services independently. Sam’s advice is to prioritize decoupling over avoiding code repetition because the tradeoff is worth it for the agility microservices promise.

内容的提问来源于stack exchange，提问作者Tuomas Toivonen