Я бы предложил следующий комментарий: с самого начала ваш подход создаст тесную связь. Это идет вразрез с вашим требованием # 3 "Слабосвязанная"
На вашей диаграмме вы определили два модуля. Основной модуль и Модуль 2. Я думаю, что эти два модуля довольно сильно отличаются друг от друга. Под этим я подразумеваю, что вы можете разработать их полностью отдельно, а затем подключить к ним, потому что проблемы бизнеса, которые они решают, различны.
Однако, ваш текущий архитектурный подход:
- Объединяет данные основного модуля и модуля 2 в одну базу данных
- Объединяет бизнес-объекты основного модуля и модуля 2 в один бизнес-уровень
- Объединяет службы основного модуля и модуля 2 в один и тот же уровень обслуживания
- Соединяет развертывание и управление основным модулем и модулем 2
Что может стоить рассмотреть: собрать основной модуль и модуль 2 в виде отдельных вертикальных служебных стеков.
Я имею в виду, что главный модуль и модуль 2 становятся основным обслуживанием и обслуживанием 2
Каждый сервис имеет свою собственную базу данных, свой бизнес-уровень, свой сервисный уровень и собственные компоненты пользовательского интерфейса.
Однако это вызывает беспокойство: как Main Service и Service 2 могут работать вместе для создания моего продукта?
Для решения этой проблемы:
На пользовательском интерфейсе вы соединяете ваш внешний интерфейс, используя код на стороне клиента для загрузки ответов из основного сервиса и сервиса 2 в одно представление.
В серверной части вы используете общедоступную рассылку сообщений, чтобы позволить Главной службе подписаться на события, происходящие в Службе 2, и наоборот.
Это приведет к созданию приложения, созданного с нуля поверх слабо связанных вертикальных служебных стеков, которые поддерживают согласованность посредством асинхронного обмена сообщениями.
Если вам необходимо добавить новый модуль в ваше приложение, вы можете создать новый стек сервисов, который поддерживает желаемую возможность, и подключить его практически без изменений в другие стеки (в идеале это единственная причина Изменение существующих стеков будет связано с тем, что они хотят подписаться на события из нового модуля).
Это совсем другой подход к тому, который вы предлагаете, но тот, который позволяет вам лучше удовлетворять требованию для слабой связи, по моему мнению.