如何在干净的架构中建模 POST 主体答案

【问题标题】：How to model POST body in a clean architecture如何在干净的架构中建模 POST 主体
【发布时间】：2021-12-22 06:46:36
【问题描述】：

我在问自己一个关于清洁架构的问题。

让我们想象一个小 api，它允许我们使用该类型的 archi 创建和获取用户。此应用程序有两个端点并将数据存储在数据库中。假设我们有一个看起来像的 db 模型

class User:
    id: int
    firstname: str
    lastname: str

首先，GET 端点将使用用例 GetUser 并使用 User 实体。该实体将如下所示：

class User:
    id: int
    firstname: str
    lastname: str

我的问题与 POST 端点有关。在这个端点中传递的数据显然只是字段firstname 和lastname。我必须在下面做另一个像这样的实体吗？

class UserRequest:
    firstname: str
    lastname: str

我觉得这不令人满意，因为将这样的实体想象为业务观点是没有意义的。尽管如此，将实体“复合”起来似乎有点不稳定，例如：

class User:
    id: Optional[int]
    firstname: str
    lastname: str

第三种选择是在用例文件中使用一个类，该类仅用于对来自 POST 请求的过去进行建模。即

class UserRequest:
    firstname: str
    lastname: str

class CreateUserUseCase:
    def __init__():
        ...
    def execute(request: UserRequest):
        ...

所以问题是：根据简洁架构原则，对来自非业务实体的 POST 请求的数据进行建模的最佳方法是什么？

非常感谢您的帮助，如果我的示例不够清楚，请随时提出问题。

史蒂夫。

【问题讨论】：

标签： python api clean-architecture python-datamodel

【解决方案1】：

在与该实体的生命周期相同的实体的上下文中查看多个端点（用例）会很有帮助，例如：

创建 (POST) 新用户“xyz”（写入数据库）
变异（POST/PUT/PATCH）用户“xyz”（写入数据库）
查询 (GET) 用户“xyz”（从数据库中读取）

上述每一个动作都应该涉及同一个业务实体User：

创建：User 实体正在使用UserRequest DTO（您已实际演示过）在用例（应用层）内部构造，然后传递给存储库对象以进行持久化。
变异：User 实体正在从数据库（存储库对象）中检索，然后修改（应用程序）最终传递给存储库对象以进行持久化。
查询：User 实体正在从数据库（存储库对象）中检索，然后传递回表示层，最终转换为响应 DTO。

CA 中的一个原则是让表示层内部的 DTO 映射到输入/输出端口/从输入/输出端口映射。 CA 的核心是域实体，由输入（表示请求 DTO）或数据库构建。

【讨论】：