Модель представления или Модель предметной области?

Question

Утром я пытаюсь понять, что для меня лучше всего делать на "большей части" части работы, которую я делаю.
Часть "в основном" появляется потому, что я унаследовал 2 системы, которые выполняют очень похожую задачу после слияния компаний.
Очень важно, чтобы эти существующие системы не подвергались риску, так как они управляют полевыми операциями для компании, и отключение = итоговый результат.
Поэтому я решил использовать Azure Service Bus для синхронизации двух базовых баз данных, и на данный момент это нормально.
Я использую опубликованные изменения из этих устаревших БД, чтобы также заполнить / синхронизировать новый экземпляр БД. Предполагается, что новый экземпляр станет консолидацией старого мира в смелый новый, и я очень усердно работаю над созданием модели предметной области, представляющей бизнес компании. Это медленно, но образование работает, и ценность в том же самом видна.
"Новая система" также будет иметь новый пользовательский интерфейс, и мы решили использовать MVC для ее реализации. У меня есть 2 парня из Индии, которые будут создавать это приложение MVC, остальное произойдет здесь, в Лондоне.

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

Нужно ли, чтобы индийские парни брали возвращенные данные и поддерживали свою собственную локальную модель представления или как? Как должна выглядеть сантехника? В течение дня работает около 80 экземпляров пользовательского интерфейса.

Модель предметной области уже явно отличается от ожидаемого представления, которое появляется на экранах.

Я был бы очень признателен за некоторые подсказки здесь, поскольку у меня есть редкая возможность "сделать все правильно"....:-) С уважением, Стив

Answer 1

1) Держите внутренний трафик компании скрытым. 2) Предоставьте REST/SOAP/ что-нибудь подходящее здесь, приложению MVC. 3) Это MVC-приложение может быть на стороне сервера, на стороне клиента, мобильным и так далее. Но он потребляет только "публичный" API. 4) Создайте сервис среднего уровня, который будет обрабатывать запросы из приложения MVC и иметь возможность общаться с другими частями корпоративной инфраструктуры.

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

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