Как вставить объекты домена в БД при запуске API
Я создаю REST API в java с трикотажем и пристанью. У меня есть сложный домен, в котором у меня есть класс (Workers). Я хочу иметь возможность динамически добавлять рабочих через POST. Однако бизнес-логика требует, чтобы у меня было несколько рабочих процессов по умолчанию с фиксированными значениями. Итак, в начале API мне нужно добавить их в мою базу данных (сейчас она находится в памяти). С точки зрения чистого кода, как лучше всего это сделать?
Я думал об инициализации моего репозитория с этими рабочими по умолчанию, но я чувствую, что это нарушает SRP для класса WorkerRepo, я чувствую, что это должна быть работа прикладного уровня, поскольку он специфичен для этого приложения, а не для домена, если это делает смысл. Куда я должен переместить логику для этой инициализации? Спасибо!
Ответы 2
Немного подумав, я перенес установку на прикладной уровень, где фактически создаю экземпляры всех своих зависимостей (в классе с именем ApplicationContext).
Я создал интерфейс WorkerContext и создал конкретную реализацию WorkerContextX, где X = NAMEOFTHEAPP. Этот класс контекста содержит все значения по умолчанию и использует введенное репо для добавления этих значений по умолчанию в репо. Итак, при запуске API в классе ApplicationContext я вызываю метод WorkerContext, который настраивает мой workerRepo.
Таким образом, я могу легко изменить стратегию установки в мгновение ока, и она больше не нарушает SRP в репо. И теперь я уважаю DIP, поскольку репозиторий (который был в домене) не полагается на вещи, которые продиктованы прикладным уровнем.
Я разместил это, так как думал, что это достойное решение и может помочь другим людям, не стесняйтесь критиковать или улучшать это решение.
С моей точки зрения, я бы разрабатывал ваши потребности так же, как я разрабатывал бы все другие варианты использования. Например. а SetupWorkerInteractor.
Я бы использовал ApplicationRunner, который инкапсулирует логику запуска приложения. Например. проанализируйте аргументы командной строки, создайте контекст приложения, вызовите процесс инициализации и запустите приложение. Конечно, я бы также разделил эти аспекты на разные классы, но я думаю, вы понимаете, что я имею в виду.
В моем случае я бы использовал ApplicationLog в качестве «представителя» вывода варианта использования установки.
Для простоты я опустил модели сущности и модели запрос/ответ.
Если я сделаю это таким образом, не имеет значения, вызывается ли SetupWorkerInputBoundary из ApplicationRunner, RestService или, например. система обмена сообщениями. Я также могу протестировать настройку, как и любой другой вариант использования.