代码之家 › 专栏 › 技术社区 › Jakub Filipczyk

Onion/Hexxagonal架构中的数据库外部化

onion-architecture domain-driven-design architecture

0

Jakub Filipczyk · 技术社区 · 10 年前

我考虑使用洋葱/六边形架构模式编写应用程序。我陷入了数据库外部化的困境。

我的应用程序需要进行一些复杂的数据查询来实现用例。我有两个集合“A”和“B”,它们是相关的。为了实现UseCase1,我需要获得所有“A”的属性与给定值匹配,并且与“B”的属性匹配其他值相关。为了完成UseCase2,我需要做一些其他的“查询”。我计划创建一个存储库接口,例如ARepository,它将数据库访问细节与域逻辑隔离开来。因为过滤规则是域规则,所以它们不能是存储库类的实现细节。

我的疑虑:

ARepository实现对“B”表进行一些SQL连接是否正常?
是否可以设计一些通用的过滤条件对象,每个UseCase都将创建自己的条件并使用它传递给ARepository::filterByCriteria()?这是一份好合同吗?
在ARepository中为每个用例创建专用方法可以吗?(我很担心将来会有很多过滤器方法,它们的名称描述了用例)

欢迎提出任何其他想法

用例示例:

UseCase1-从“A”创建报告:

应用程序应通过从用户输入中读取的过滤器+其他一些过滤器过滤“A” 过滤器。
过滤的“A”应映射到给定格式并写入到文件。
文件应传输给用户。

用例2-将“A”导出到外部系统:

应用程序应该通过从用户输入中读取的过滤器+一些其他过滤器来过滤“A”。
过滤的“A”应该被映射并通过SOAP发送到外部系统
用户应该看到导出的摘要。

2 回复 | 直到 10 年前

1

4

Aaron Hawkins 10 年前

ARepository实现对“B”表进行一些SQL连接是否正常?

是的,聚合可以加载与其他聚合共享的块。

是否可以设计一些通用的过滤条件对象,每个UseCase都将创建自己的条件并使用它传递给ARepository::filterByCriteria()?这是一份好合同吗?

据我所知,在存储库的设计上没有租户,但可以使用几种不同的技术/模式。你应该找到在你工作的语言/环境中使用的技术,并选择最适合你需要的技术。

在ARepository中为每个用例创建专用方法可以吗?(我很担心将来会有很多过滤器方法,它们的名称描述了用例)

是的,这是一个经常使用的有效模式。

作为参考,你应该看看 CQRS 。您可以有一个不同于域模型的独立报告模型,这种方法有一些有趣的好处和后果。过来看!

此外,在处理DDD时,请记住,有界上下文非常重要,域层应该是业务及其交互的表达形式。在发布DDD问题时,您可能应该始终提供有边界的上下文。我之所以这么说,是因为无法知道您提供的用例与您的业务有何关联。它们甚至可能根本不属于域层。

举个例子,假设您有用例A:用户可以选择发票模板来应用于他们生成的发票。

如果您是一个发票服务,那么这个用例很可能属于您的域层,我认为Invoice可能是一个聚合根。

如果您是一个地毯清洁服务,那么这个用例可能只是UI问题,根本不属于您的领域层。在这种情况下,这可能更适合单独使用UI或应用程序服务。

所有这些都是说,根据您的业务,用例可能是或可能不是域层的一部分。在DDD中,上下文是一切。

2

0

Stephan Eggermont 10 年前

您的用例中存在重复。如果他们很好地描述了企业思考和谈论系统的方式,那么可以为他们设置专门的切入点。然而,重要的是要确保系统地消除其实施中的重复。

我经常看到的一个问题是,有太多的开发人员使用复制和粘贴样式来实现类似的用例,并且没有花时间来沟通和重构。我总是在新的(对我来说)代码库上运行克隆检测器。