Ищите предложения о том, как подойти к этой проблеме и понять, действительно ли дизайн, управляемый доменом, действительно лучший образец здесь.
Мой клиент находится в процессе реорганизации своего почти устаревшего стека инструментов и сервисов. Клиент - это быстро развивающийся интернет-магазин. Основным продуктом является большой веб-сайт электронной коммерции. Вокруг этого сайта у клиента есть множество каналов данных, которые он предоставляет своим партнерам. Множество внутренних приложений, помогающих в маркетинге, продажах, отчетности и т. Д. Множество приложений поддержки пользователей и партнеров. Большое количество различных синхронизаций данных, заданий ETL и т. Д. Вы получаете картину.
Хранилища данных и поставщики данных также многочисленны. Облачное мега-масштабируемое хранилище NOSQL предоставляет большую часть информации на общедоступном веб-сайте. SQL-серверы с рядом баз данных предоставляют данные для внутренних приложений. Существуют также специальные серверы, предназначенные только для поиска, которые обеспечивают мегаскабельные возможности поиска, а также другие каналы, которые приложения используют у различных сторонних поставщиков. Если будет принят DDD, план будет состоять в том, чтобы различные группы объектов хранилища наследовали от базовых классов хранилища данных, специфичных для хранилища
Клиент выполнил упражнение, в котором он наметил большинство своих бизнес-сущностей на «общем» уровне: имена и отношения сущностей. Помимо этого «общего» уровня, существует достаточное количество повторного использования различных конкретных объектов в приложениях, а также приличное количество объектов, которые могут отличаться по своей реализации в зависимости от приложения.
Например: сущность Order на веб-сайте электронной коммерции может выглядеть как X, в то время как для приложения, поддерживающего вызовы поддержки, например Y, так и для того, кто выполняет анализ мошенничества, например Z.
Я ищу предложения о том, как адаптировать DDD или другой архитектурный шаблон для обработки этого гигантского беспорядка: иметь надежную корпоративную стратегию, которая облегчает повторное использование и позволяет при необходимости разделять логику. В дополнение к обычным (масштабируемым, гибким, адаптируемым, тестируемым на модуле, простым и т. Д.) Критериям.
Из-за разных хранилищ данных структура DTO выглядит существенно отличной от хранилища данных к хранилищу данных. Из-за различных бизнес-потребностей различным приложениям требуются разные версии определенных объектов, и поскольку компания быстро расширяется, будущее крайне нестабильно, а гибкость имеет первостепенное значение.
Я полагаю, что моя самая большая проблема - найти способ разделить бизнес-модель на разные домены и при этом сохранить ее вместе, когда существует большое количество совместного использования или повторного использования, и при этом возможность перехода на высокий уровень изменений.
Спасибо за все ваши предложения
P.S. Магазин - это магазин Microsoft. VS2010 / .NET / SQL / Azure