外部服务(API)是否适合存储库的DDD定义?

时间:2019-01-03 10:52:03

标签: repository domain-driven-design repository-pattern ddd-repositories

除了大师之外,我还没有找到关于该主题的任何具体内容

  

还有其他方法可以实现反腐败层,例如通过   存储库的工具(12)。但是,由于通常使用存储库   持久化并重构聚合,通过这种方式创建价值对象   似乎放错了地方。如果我们的目标是从反腐败中产生集料,   位置层,存储库可能是更自然的来源。

来自弗农·沃恩。

我担心的是,在DDD文献中,大多数ORM /查询都用作存储库的示例。我的项目在域逻辑上非常稀缺,因为它主要是几个API的包装,并结合了这些Context的结果。该项目的职责范围很广,可以适合整个企业的许多领域/背景。从一开始就强制执行的唯一架构规则是洋葱架构,至少DDD技术建模概念似乎适合我。我必须说,在这个正在进行的特定项目中很难推断出领域。

3 个答案:

答案 0 :(得分:1)

  

外部服务(API)是否符合存储库的DDD定义?

也许吗?

  

存储库解决了[域对象]生命周期的中部和结尾,提供了在封装涉及的庞大基础结构的同时查找和检索持久对象的方法。

存储库是一种模式,它是由关注点分离的概念驱动的-在处理域逻辑时,您不必大惊小怪的持久化细节。

答案 1 :(得分:0)

以现代JavaScript网站为例。您将有大量的REST调用来创建/查找/更新/删除域对象。

对于服务器应用程序,您将拥有一个数据库和一个DAO实现,作为数据库的客户端接口。在您的Web应用程序中,您还将具有一些REST客户端功能,作为服务器应用程序的客户端界面。无论客户端接口的实现是否访问数据库/服务器/文件系统等中的数据,这两个库均被视为存储库。

答案 2 :(得分:0)

DDD仅与域有关。您的应用如何持久化实体的详细信息无关紧要。这就是为什么要在域中定义存储库的接口(对于.NET)的原因,但是实际的实现是代码基础结构的一部分。

存储库不过是让您对实体执行“ CRUD”操作而无需担心如何完成的一种模式。请记住,您的客户端类(使用存储库的客户端类)只能看到公开的公共方法。不管发生什么,这都是一个谜:)

DDD说,给我一个界面供我操作。你怎么做,这就是你的问题。您可以使用外部API(例如Twitter API),文本文件,ORM(与数据库的直接连接)有效地保留实体。 DDD不在乎。