Концепция архитектуры для приложения фоновой синхронизации - PullRequest
0 голосов
/ 12 февраля 2020

В настоящее время я борюсь с архитектурой своего приложения при рефакторинге. Предполагается, что большую часть времени он будет работать в фоновом режиме, управляемом cronjobs, а также заданиями в очереди, управляемыми 'supervisor'.

Цель приложения - собрать данные документа из API (исходной системы) и распределить эти данные по разным адресатам (API, файловая система и т. д. c.).

Мой подход состоит в том, чтобы разделить их на разные модули, чтобы сделать их более гибкими и обеспечить лучшую расширяемость. Каждый модуль будет иметь свои собственные службы, а некоторые из них - свои собственные репозитории и модели. Не каждый сервис будет иметь соответствующую модель и / или хранилище. В основном у меня есть только одна таблица с данными документа. Но есть много проверок и случаев, чтобы привести данные в правильную структуру для соответствующей цели / распределения. Поэтому я бы разделил логи c на несколько сервисов на модуль. Например, одна служба отвечает за обработку метаданных, а другая загружает файл, относящийся к документу, а третья получает данные из другого API, например, для перевода.

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

Это первая точка, в которой я немного не уверен из-за SingleResponsibilityPrinciple. Должен ли я разделить первый модуль на два отдельных? Один отвечает только за получение данных, а другой - за их сохранение в индексе? Или это нормально, чтобы собирать и хранить одновременно, поскольку существует только одна исходная система и, следовательно, только один индекс?

Другие модули распространения модулей) будут иметь бизнес-логику c для преобразования данных из указатель на желаемую структуру, так что только они знают об этих специальностях.

Хотя некоторые изменения в документах должны распространяться как можно скорее, другие модули распространения должны выполнять свою работу только один раз в день или запускаться только вручную. В то же время я хочу предоставить все функциональные возможности, запускаемые вручную с помощью внешнего интерфейса. Это делается для исправления ошибки, которая происходит во время автоматического запуска c (например, просто «повторить что-либо») или для проверки какой-либо обработки. Кроме того, особенно тесты должны выполняться с особыми параметрами соответственно в различных условиях окружающей среды. Хотя это может быть очень похоже на модульные тесты, эти тесты больше ориентированы на обработку «реальных» данных, поскольку при обработке могут возникать некоторые ошибки, которые могут быть исправлены также в исходной системе.

Как можно Я предоставляю функциональность как запланированную команду, так и из метода контроллера, выполняя последний, должна быть возможность немного изменить ее поведение. Например, если измененный документ распознается «автоматизированной частью» приложения, отправляется задание для запроса API с этими изменениями. Я также хочу запустить logi c соответствующего модуля распространения, инициируемого вручную для любой (не обязательно измененной) записи документа, не имея задания, и его не следует отправлять по назначению, но созданный запрос должен быть напечатан на Пользователь в веб-интерфейсе.

Когда я думаю с точки зрения общего подхода с веб-интерфейсом, я отправляю запрос в метод контроллера. Там я бы вводил несколько сервисов (которые могут также зависеть от других классов сервисов) и использовал их в методе контроллера.

Рекомендуется ли затем вызывать метод контроллера из запланированной команды, поскольку внешний интерфейс не является реальным ядром приложения, но это команда, выполняющая свою работу без какого-либо человеческого взаимодействия. Или я должен создать "главный" -сервис для каждого модуля, который затем зависит от других классов обслуживания, в то время как любая точка приложения, которая нуждается в этой функциональности, просто вызывает этот "основной" -сервис?

В моем текущем В состоянии познания мне всегда нужно место, где я вызываю разные методы в определенном порядке. В этом месте никакие проверки или бизнес логи c не должны быть сделаны. По сути это может быть метод контроллера. Но я также уже знаю, что я должен держать контроллер как можно меньше.

Я надеюсь, что смогу сделать это немного понятным, и я был бы очень рад, если бы мог получить какой-нибудь совет, как создать этот вид модульного приложения.

Большое спасибо, Danaq

...