Блог

Я задаю себе вопрос о чистой архитектуре.

Давайте представим себе небольшой api, который позволяет нам создавать и получать пользователей, использующих этот тип archi. Это приложение имеет две конечные точки и хранит данные в базе данных. Допустим, у нас есть модель бд, которая выглядит так

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

Во-первых, конечная точка GET будет использовать usecase 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  

Третий вариант-использовать класс внутри файла usecase, который предназначен только для моделирования прошлого, поступающего из запроса POST. ie

 class UserRequest:  firstname: str  lastname: str  class CreateUserUseCase:  def __init__():  ...  def execute(request: UserRequest):  ...  

Итак, вопрос в следующем: в соответствии с принципами чистой архитектуры, каков наилучший способ моделирования данных, поступающих из запроса POST, который не является бизнес-объектом?

Большое спасибо за вашу помощь, и не стесняйтесь задавать вопросы, если мои примеры недостаточно ясны.

Стеф.

Было бы полезно просмотреть несколько конечных точек (вариантов использования) в контексте той же сущности, что и жизненный цикл этой сущности, например:

1. Создание (ПУБЛИКАЦИЯ) нового пользователя «xyz» (запись в базу данных)
2. Изменение (ЗАПИСЬ/РАЗМЕЩЕНИЕ/ИСПРАВЛЕНИЕ) пользователя «xyz» (запись в базу данных)
3. Запрос (ПОЛУЧЕНИЕ) пользователя «xyz» (чтение из базы данных)

В каждом из вышеперечисленных действий должен участвовать один и тот же хозяйствующий субъект User :

1. Создание: User сущность создается внутри прецедента (уровень приложения) с использованием UserRequest DTO (вы фактически продемонстрировали именно это), а затем передается объекту репозитория для сохранения.
2. Изменение: User сущность извлекается из базы данных (объект репозитория), затем изменяется (приложение), наконец, передается объекту репозитория для сохранения.
3. Запрос: User сущность извлекается из базы данных (объект репозитория), затем передается обратно на уровень представления, наконец, преобразуется в DTO ответа.

Один из принципов в CA заключается в том, чтобы DTO внутри уровня представления отображались на порты ввода/вывода / из них. Сердцем ЦС являются доменные сущности, создаваемые либо на основе входных данных (представляющих DTO запроса), либо из базы данных.