英文:
Relating creation and update request use cases to entity in clean architecture REST
问题
让我们假设我正在构建一个允许对某种对象类型 A 进行基本 CRUD 操作的 REST 服务。
我正在使用干净的架构，因此：
-
A 本身的定义位于领域层。这包括与其相关的任何业务逻辑，比如两个字段之间的约束关系（例如年龄和出生日期）。
-
CRUD 操作的高级逻辑，包括任何特定于应用程序的验证、数据生成和通用数据访问调用，将位于用例层。
-
持久数据访问、REST 框架和特定于 HTTP 的逻辑将位于基础设施层，实现用例层中定义的端口接口。
现在，我想要实现更新用例。这个用例知道如何处理的格式不完全是 A，而是一个不同但相似的模型，可以具有缺失的字段（用户可能只想更新对象的一些字段）。这也是我的数据访问端口接口使用的模型，因为它需要与更新用例使用的格式相同。
我的问题是，在这种情况下，我的服务器如何强制执行应用程序不可知（领域）的业务规则？在任何时候，更新请求都没有通过 A 的领域定义进行翻译。我的更新请求不能以任何实质性的方式扩展或包含 A，因为它甚至可能只包含其中一个字段，或者根本不包含任何字段。
在我的实际工作中，我尝试解决这个问题时，我将更新请求放在领域层中，将应用程序不可知的规则手动添加到该模型中。但毫无疑问，这是错误的方法，因为更新请求肯定是特定于应用程序的格式。
是否有已知的、推荐的处理这个问题的方式？
英文:
Let's say I am building a basic REST allowing CRUD operations on some object type A.
I am using clean architecture, so
-
The definition of A itself sits in the Domain layer. This includes any business logic inherent to it, such as a constrained relation between two fields (e.g age and birthdate)
-
The high-level logic of the CRUD operations, including any app specific validation, data generation, and generic data access calls, will sit in the Use Case Layer.
-
Persistent Data Access, REST Frameworks and HTTP-specific logic will sit in the Infrastructure layer, implementing port interfaces defined in the Use Case layer.
Now, I would like to implement the Update Use Case. The format that this use case knows to how to handle is not exactly A, but a different, similar model that can have missing fields (a user my want to only update some of his object's fields). This is also the model used by my Data Access port interface, as it needs to be the same format the Update Use Case uses.
My question is, how, in this scenario, does my server enforce the application agnostic (domain) business rules? At no point does the update request gets translated through the domain definition of A. My Update Request cannot extend or contain A in any real manner, since it may contain even just one field of it, or no fields at all.
In my trying to solve this problem on my IRL job, I put the Update Request in the domain layer, including app agnostic rules into that model "by hand". Surely that is the wrong approach, since the Update Request is definitely an application specific format.
Is there a known, recommended way to handle this issue?
答案1
得分: 1
以下是翻译好的部分：
- 在这些情况下，我通常会这样做：
- 我的实体/聚合
A必须有执行更新操作的方法/命令，检查所有必要的业务规则 UpdateUseCase（我只描述快乐路径）- 接收要修改的实体的标识
- 接收要更新的数据
- 从持久性存储中读取要修改的整个实体（按标识）
- 使用实体的方法/命令来修改它
- 使用持久性存储实体
现在，我想要实现更新用例。此用例知道如何处理的格式不完全是 A，而是一个不同的、类似的模型，可以具有缺少的字段（用户可能只想更新对象的一些字段）。
让我们称之为 ToChangeA
我的数据访问端口接口也使用了这个模型，因为它需要与更新用例使用的格式相同。
问题在于，您的数据访问端口接口应该只接受 A 的实例，而不是直接接受 ToChangeA。
并且您可以使用域层的方法 A.update(ToChangeA) 来获取更新后的 A 类型的实例。
我希望现在更清楚了。
英文:
What I usually do in these cases is:
- my entity/aggregate
Amust have methods/commands to perform the update action, checking all needed business rules - the
UpdateUseCase(I describe just the happy path)- receives the id of the entity to modify
- receives the data to be updated
- reads (by id) from the persistence the whole entity to be modified
- use the entity method/command to modify it
- store the entity using the persistance
>Now, I would like to implement the Update Use Case. The format that this use case knows to how to handle is not exactly A, but a different, similar model that can have missing fields (a user my want to only update some of his object's fields).
Let's call it ToChangeA
>This is also the model used by my Data Access port interface, as it needs to be the same format the Update Use Case uses.
What's wrong here is that your DataAccessPortInterface should accept only instancies of A, not directly ToChangeA.
And you get your updated instance of type A using the method A.update(ToChangeA) of the domain layer.
I hope it's clearer now
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论