Начиная с шаблона DDD на бизнес-уровне

Я разделил различные уровни (проекты библиотеки классов) в моем обозревателе решений следующим образом:

Я хочу использовать микро-ORM PetaPoco и мне предложили чтобы добавить PetaPoco в слой репозитория. Как и было предложено, я добавил PetaPoco в проект Repository и сгенерировал модель из базы данных. Теперь автоматически сгенерированные POCO находятся в репозитории.

Я не слежу за тем, чтобы реализовать DDD, мне нужны все POCO в модели, то есть бизнес-уровень.

Я добавил WebForm для входа пользователя в уровень WebUI. Теперь, когда нужно использовать DDD, нужен ли мне интерфейс в модели? Где написать метод проверки входа?


person RKh    schedule 09.09.2012    source источник


Ответы (1)


Я настоятельно рекомендую вам (пере) прочитать книгу Эрика Эванса по предметно-ориентированному дизайну. Также вы должны смотреть MR. Видео Эванса по книге. DDD НЕ ЯВЛЯЕТСЯ репозиториями, базами данных, сборками или логином пользователя.

Также существует вероятность, что DDD на самом деле не то, что вы ищете. Похоже, вы ищете многоуровневый подход с пользовательским интерфейсом поверх некоторых сущностей / приложений-сервисов поверх некоторых репозиториев поверх базы данных. В зависимости от того, что вы создаете, это может быть все, что вам нужно.

Если вы хотите использовать PetaPoco, и если ваш «orm» генерирует «модели» из базы данных, то не имеет большого смысла разделять их в разных проектах. Тот факт, что модели генерируются ормом (и тот факт, что в будущем может потребоваться повторная генерация), делает их весьма связанными с ормом, поэтому их перемещение в отдельную сборку вам ничего не стоит.

Чтобы ответить на ваш вопрос ValidateLogin, я бы предложил переместить весь код, связанный с аутентификацией, на уровень инфраструктуры, который ортогонален (вертикален) другим уровням. Пользователи приложения не обязательно должны быть «сущностями». Возможно, вам также удастся иметь приложение-сервис на уровне модели, который обрабатывает аутентификацию, но я обычно считал, что auth является проблемой инфраструктуры, а не бизнесом.

В конце я предлагаю вам ознакомиться с недостатками и сильными сторонами такой архитектуры, а затем решить, подходит ли она для того, что вы строите. С другой стороны, вы должны знать, что DDD не из дешевых в сборке и (как сказал г-н Эванд) вы, вероятно, не сделаете это правильно в первые несколько раз.

person Iulian Margarintescu    schedule 09.09.2012
comment
Спасибо. Что, если я проигнорирую ORM и буду использовать LINQ? Мне нужно создать интерфейс для входа в систему? - person RKh; 10.09.2012
comment
На самом деле это не имеет значения. Сначала вам нужно решить, является ли процесс входа в систему частью вашего бизнес-процесса или это просто проблема инфраструктуры. Если это часть бизнес-процесса, тогда у вас будет сущность User и служба-приложение, способные выполнять проверку / аутентификацию. Если это проблема инфраструктуры, то для этого вам понадобится компонент инфраструктуры. - person Iulian Margarintescu; 10.09.2012