Мы разрабатываем архитектуру (с нуля) на основе доменного дизайна (DDD), имеющую примерно три ограниченных контекста, каждый из которых соответствует одному базовому домену. Существует также ограниченный контекст (Generi c субдомен) для мониторинга наших приложений, а также ограниченный контекст (Generi c субдомен) для выполнения запланированных заданий (поступающих из основных доменов, но рассматриваемых как черные ящики). планировщик).
Есть еще два требования, для которых мы не уверены, как их смоделировать:
- Отчетность (то есть отчеты с точностью до пикселя)
- Взаимодействие с внешними системами, которые не являются частью нашего домена (например, подготовка пакета XML файлов, готовых для получения через веб-службу (WSDL) ночью ночью правительство или предоставление части модели одного базового домена в виде упрощенной SQL базы данных, готовой для запроса третьими сторонами)
Мы можем представить два подхода каждый:
Интеграция отчетности и взаимодействия в ограниченный контекст, которому они принадлежат , что потенциально может дублировать код инфраструктуры.
- В случае o f При составлении отчетов мы регистрируем файлы определений отчетов (например, RDL от Microsoft) в Git репозиториях отдельных ограниченных контекстов и разворачиваем их на централизованном сервере отчетов.
- В случае взаимодействия мы бы разработать вышеупомянутые XML -генерирующую логику c и веб-службу как проекты в репозитории Git этого ограниченного контекста и развернуть его как часть этого ограниченного контекста.
Создание назначенных ограниченных контекстов для создания отчетов и взаимодействия каждого из них, тем самым объединяя технологии, но распространяя аспекты основных доменов.
- В случае создания отчетов мы будем управлять всеми файлы определений отчетов, принадлежащие различным основным доменам в указанном хранилище Git, вместе со всем кодом, необходимым для создания и отображения отчетов.
- В случае интерфейса мы бы управляли всеми «портами и адаптерами» в единый репозиторий Git для всех основных доменов, потенциально использующий Территориальный набор интерфейсных технологий, таких как REST или WSDL или OpenAPI или SQL. Этот ограниченный контекст будет затем использовать опубликованные языки (в нашем случае это все веб-API, использующие стандарт Open API) ограниченных контекстов, с которыми он должен взаимодействовать, и предоставит себя интерфейсом для внешнего мира.
Я думаю, что обсуждение сводится к двум независимым аспектам: технология и бизнес. Должны ли мы хранить все, что связано с бизнесом, вместе, или мы должны объединяться вокруг технологии / инфраструктуры (то есть, все, что связано с интерфейсом и все, что связано с отчетами)?