DDD в масштабе предприятия?

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

Мой клиент находится в процесс реорганизации почти устаревшего набора инструментов и услуг. Клиент - это быстроразвивающийся интернет-магазин. Его основной продукт - большой веб-сайт электронной коммерции. Вокруг этого веб-сайта у клиента есть множество каналов данных, которые он предоставляет своим партнерам. Множество внутренних приложений для помощи в маркетинге, продажах, отчетности и т. Д. Множество приложений для поддержки пользователей и партнеров. Большое количество различных синхронизаций данных, заданий ETL и т. Д. Вы понимаете.

Хранилища данных и поставщики данных также многочисленны. Облачное мега-масштабируемое хранилище NOSQL предоставляет большую часть информации на общедоступном веб-сайте. SQL-серверы с рядом баз данных предоставляют данные внутренним приложениям. Существуют также специальные серверы, предназначенные только для поиска, для обеспечения возможности мегаскалиброванного поиска, а также другие каналы, которые приложения используют от различных сторонних поставщиков. Если будет принят DDD, план будет заключаться в том, чтобы различные группы объектов репозитория унаследовали от базовых классов репозитория, специфичных для хранилища данных

. Клиент провел упражнение, в ходе которого они отобразили большинство своих бизнес-объектов на " общий "уровень: имена сущностей и отношения. Вне этого «общего» уровня существует приличное количество повторного использования различных конкретных объектов в приложениях, а также существует приличное количество сущностей, реализация которых может отличаться в зависимости от приложения.

Например: Порядок объект на веб-сайте электронной коммерции может выглядеть как X, в то время как для приложения, которое обрабатывает обращения в службу поддержки, например Y, и, кроме того, для кого-то, выполняющего анализ мошенничества, например Z.

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

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

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

Спасибо за все ваши предложения

PS Магазин - это магазин Microsoft. VS2010 / .NET / SQL / Azure