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