我正在构建一个集成Plaid API以访问用户银行信息(登录、帐户、交易等)的应用程序。我正在尝试遵循 DDD 原则。
以下是 Plaid API 流程如何工作的总体思路:
- 用户为某个银行机构提供他的电子邮件/密码。如果有效,则会创建一个格子项目。该对象将用户与一组银行凭证相关联,并包含一个访问令牌,可用于进一步与 API 交互。
- 每个格子项目都可以访问一组特定的银行帐户。
- 每个银行账户都有一组交易
到目前为止,我在域层中创建了 3 个实体:Item、Account 和 Transaction。我为每个存储库创建了一个包含基本 CRUD 操作的存储库。
public class Item
{
public string Id { get; set; }
public string AccessToken { get; set; }
public string UserId { get; set; }
...
}
public class Account
{
public string Id { get; set; }
public string ItemId { get; set;
...
}
public class Transaction
{
public string Id { get; set; }
public string AccountId { get; set;
...
}
如您所见,这些实体之间的关系是:
用户有 项目-> 项目有账户 ->账户有 交易
我的问题是,当我需要通过间接父母找到实体时会发生什么?例如:GetTransactionsByItemId或GetAccountsByUserId。基于DDD,这个逻辑该往哪里走?
由于我的数据的结构方式(一对多关系的 No-SQL 链),我知道我必须分多个步骤进行此类查询。但是,我读过 Repository 应该只关心它自己的实体,所以我怀疑将 ItemsRepository 和 AccountsRepository 注入 TransactionsRepository 以添加GetTransactionsByItemId方法可能不是一个好主意。
我还阅读了有关将许多存储库注入服务并从内部管理所有这些“连接”的信息。但是,我想不出这个服务的名称,所以我担心这是因为从概念上讲这没有多大意义。
我还阅读了有关聚合的信息,但我不确定我是否识别出这些实体中的根。
我能想到的另一个选择是尝试通过向每个事务添加 ItemId 来缩短关系。但是,由于我如何从 api 获取数据,这将需要一个 hack。