Szy*_*947 0 c# domain-driven-design microservices
想象一下使用微服务的 OAuth 提供商。我们将为授权端点、令牌端点等提供微服务。
For example, every endpoint is different microservice and most endpoints will need to retrieve client by id to authenticate request. So how should I share method to get client from database, model for client and all related to it entities?
How shall I share common methods and classes between microservices?
If microservice A depends on microservice B, then I need to do communication between them over HTTP or I just can add project reference? Or maybe situation where some microservice depends on another is bad and says that our services are too micro?
Does scenario where we use DDD in our microservices says that our microservices are too big (or it adds too many complexity)? If they are really micro, doesn't it mean that some simple folders like Models, Services and Endpoints are enough?
那么我应该如何共享从数据库获取客户端的方法、客户端模型以及所有与其相关的实体？
你不需要，因为在微服务架构中，在微服务之间共享数据库通常是一种非常糟糕的做法。
如何在微服务之间共享通用方法和类？
一般来说 - 你不应该。您可以维护多个合约库（但您应该首先考虑某种模式注册表）和横切关注点，但仅此而已。
如果微服务A依赖于微服务B，
问题是您应该避免传统意义上的服务相互依赖。服务应尽可能松散耦合
然后我需要通过 HTTP 在它们之间进行通信
在某些情况下，您需要某种 RPC，但一般方法是尝试避免服务之间的同步通信，而采用异步通信（例如，通过某种消息总线）
我可以添加项目参考吗？
如果您可以将一个微服务的引用添加到另一个微服务上，那么您就没有微服务。
如果它们真的很微小，那不是意味着
我认为“微服务”这个术语一般来说并没有那么明确的定义，而且不同地方的差异可能很大。
请注意，微服务架构的目标并不是将每个端点拆分为单独的服务，实际上这样做可能会适得其反。我认为主要目标是将您的系统拆分为松散耦合甚至独立的组件（最好尽可能小），实际上，如果您发现多个组件紧密耦合，那么在某些情况下您可以将它们重新组合起来（或重新设计架构，以便它们可以解耦）。
我强烈建议您学习以下资源：