在微服务体系结构中，为所有业务服务都具有单独的DAO服务是件好事还是应该让服务中的所有层都完好无损？就我而言，我正在构建一个小型银行应用程序，其中包含以下服务
cbs-accountsummary
cbs-payments
cbs-accounts
cbs-loan
cbs-deposits
所以我真的也需要以下服务
cbs-accountsummary-dao
cbs-payments-dao
cbs-accounts-dao
cbs-loan-dao
cbs-deposits-dao
或者将DAO作为业务服务的一部分很好。我真的很想知道它在现实生活中的应用情况。
答案 0 :(得分：1)
正如已经说过的，我不会去寻求单独的DAO服务。微服务应该控制它所负责的有限上下文的所有方面，包括持久性。
想象一下，如果有单独的DAO服务，那么什么会阻止客户端通过所述服务修改微服务本身的数据？微服务将业务逻辑应用到其域对象上，并将其持久化（如果违反业务规则）。您永远都不想绕开它。参见Sam Newmans的书Building Microservices的“凝聚力行为”。
答案 1 :(得分：1)
在微服务体系结构中，您将域划分为微服务，每个微服务将具有自己的：api，业务逻辑和数据访问。
您的示例
例如，在您的情况下，微服务“ cbs-payments”将公开其自己的API，以及一个业务层（支付域的域逻辑）和数据访问层。微服务将负责从api到数据持久性的整个请求范围。这可能包括api，业务逻辑，缓存，数据库和其他内容。
让我们说一下您是否有一个创建付款api调用。您将调用POST api / payments之类的微服务REST api，它将处理请求，应用一些业务规则（验证和其他）并将其保存到微服务特定的数据库中。所有这些代码都将在您的微服务中。
混乱
也许您正在使用的系统中，体系结构拆分不是基于域而是基于其他条件进行的。 通常，微服务是根据某些域边界（例如您的示例）进行划分的。这些微服务中的每一个都是隔离的。无论业务逻辑，数据访问逻辑还是任何其他逻辑，它仍然是该微服务的一部分。 通常人们将DDD（域驱动设计）与微服务一起使用。这也是使用存储库和工作单元设计模式的一种常见方法。您可以创建通用存储库/工作单元类，以帮助数据库交互。如果您使用的是微服务架构，则可以将这些通用实现提取到某个库中，并在每个微服务中使用它们（如果需要，可以对其进行扩展）。仍然可以在微服务代码中使用该代码。