微服务架构：数据访问服务答案

【问题标题】：Micro service architecture : Data Access services微服务架构：数据访问服务
【发布时间】：2019-11-11 09:31:16
【问题描述】：

在微服务架构中，是否应该为所有业务服务提供单独的 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 作为业务服务的一部分是否可以。我真的很想知道它在现实生活中的应用。

【问题讨论】：

“所有层”是什么意思？通常如果你有微服务，每个服务管理自己的领域数据模型；如果有交换接口（例如摘要需要来自大多数其他接口的数据），它将包含在传入数据和内部模型之间转换的映射类。
控制器、服务和 dao 中的所有层。 @daniu 但是我可以从您那里了解到“每个服务管理自己的域数据模型”每个服务都应该有自己的 DAO 和模型对象，它将与自己的数据库进行对话。所以总而言之，单一服务应该包含从呈现到 DAO 的所有内容。

标签： microservices

【解决方案1】：

在微服务架构中，您将域拆分为微服务，每个微服务都有自己的：api、业务逻辑和数据访问。

你的例子

例如，在您的情况下，微服务“cbs-payments”将公开其自己的 API，以及业务层（支付域的域逻辑）和数据访问层。微服务将负责从 api 到数据持久化的整个请求范围。这可能包括 api、业务逻辑、缓存、数据库和其他东西。

假设您有创建付款 api 调用。您将调用您的微服务 REST api，例如 POST api/payments，它将处理请求，应用一些业务规则（验证和其他）并将其保存到微服务特定数据库。所有这些代码都将在您的微服务中。

困惑

也许您使用的系统架构拆分不是基于域而是基于其他一些标准。通常，微服务会根据您的示例中的某些域边界进行拆分。这些微服务中的每一个都是隔离的。无论业务逻辑、数据访问逻辑或任何其他逻辑如何，它仍然是该微服务的一部分。通常人们将 DDD（域驱动设计）与微服务一起使用。这也是使用存储库和工作单元设计模式的常用方法。您可以创建有助于数据库交互的通用存储库/工作单元类。如果您使用的是微服务架构，您可以将这些通用实现提取到某个库中并在每个微服务中使用它们（如果需要，可以扩展它们）。您仍然会在您的微服务代码中使用该代码。

【讨论】：

【解决方案2】：

如前所述，我不会选择单独的 DAO 服务。微服务应该控制它负责的有界上下文的所有方面，这包括持久性。

想象一下，如果有单独的 DAO 服务，什么会阻止客户端通过所述服务修改微服务本身的数据？微服务将业务逻辑应用到它的域对象上，并持久化它们（以防违反业务规则）。你永远不希望这被规避。请参阅 Sam Newmans 书中 Building Microservices 的“凝聚力行为”。

【讨论】：