У меня есть устаревшее приложение, которое я переделываю, потому что это то, что мы называем «шариком грязи» на данный момент, без наслоений или SOC вообще. Команда привыкла работать по модульному принципу. Это означает, что есть команда, которая работает над «обучением», «Возможностями трудоустройства», которая работает над модулем, управляющим «Дежурным планированием (военным)». У нас есть один веб-сайт, представляющий эти области нашим клиентам в качестве портала услуг, одну базу данных и несколько внешних приложений, которые мы обслуживаем.
У меня хорошо получается переделать большинство слоев, кроме как правильно разделить домен (я должен упомянуть, что мы используем .Net 4.0). Моя первоначальная мысль заключалась в том, что это были ограниченные контексты из-за того, как они работали, у них действительно, казалось, были разные группы пользователей, но я верю, что в настоящее время реальность такова, что люди, которые используют этот сайт, могут и действительно используют много областей одновременно. Конечно, некоторые группы используют ТОЛЬКО один сервис, но многие используют несколько. Целью сайта является универсальное управление «членами». Между модулями у нас есть классы, уникальные для модуля, а затем у нас есть несколько общих классов, например, концепция члена известна и используется всеми модулями. Член на самом деле является основной концепцией, сайт добавляет ценность, отслеживая информацию о члене сразу во всех этих областях. По сути, это несколько тесно связанных, но отдельных областей в системе и общая область. Я надеюсь, что это достаточно ясно, чтобы ответить на мой вопрос.
Я думаю, что у меня все еще будет общее ядро, даже если это не ограниченные контексты, для общих объектов и интерфейсов общих доменов, таких как общий интерфейс репозитория. Было бы разумно поместить весь общий код (общий репозиторий, модель основного домена, общее ядро и т. Д.) В одно и то же пространство имен или иерархию пространств имен, и мне следует изолировать это пространство имен в его собственной сборке? Аналогично, я бы затем разбил каждую область («обучение», «Возможности» ...) на свои собственные сборки или лучше, чтобы они были все в одной сборке и логически разбивали их по пространству имен. С одной стороны, немного проще увидеть модули физически разделенными, но меня беспокоят ситуации, когда два модуля должны работать вместе для решения проблемы. Как они будут общаться и сохранять ацикличность (я полагаю, через сервисы на уровне приложений).
т. (Сводка опций):
Domain.Model (dll)
- Domain.Model.Core
- Ядро (общие сущности и модель основного домена)
- Репозиторий Рамки
-- так далее...
- Domain.Model.Training
- Domain.Model.Opportunities
...
или
Domain.Model.Core
Domain.Model.Training (dll)
Domain.Model.Opportunities (dll)
(Как тренировка и возможности работают вместе?)
Большое спасибо за ваше время,