Как реализовать поддерживаемое и слабо связанное приложение с использованием DDD и SRP?

Поводом для этого вопроса является то, что я задавался вопросом, как сшить все эти разные концепции вместе. Существует много примеров и обсуждений в отношении DDD, Injection Dependency Injection, CQRS, SOA, MVC, но не так много примеров того, как собрать их все вместе гибким способом.

Моя цель:

Разработка модулей, которые практически без изменений могут стоять самостоятельно
Изменение или переделка пользовательского интерфейса должна быть как можно более легкой (т.е. пользовательский интерфейс должен делать как можно меньше и быть "глупым"
Использование документированных шаблонов и принципов

Чтобы упростить задание конкретного вопроса, основная архитектура теперь выглядит следующим образом:

В этом примере показано, как добавить заметку к сотруднику. Управление сотрудниками - это один ограниченный контекст. Сотрудник имеет несколько свойств, среди которых ICollection<Note>.

Связанный контекст в моем понимании логического места для разделения кода. Каждый BC является модулем. В большинстве случаев я нахожу, что каждый из них может при необходимости использовать свой собственный интерфейс (т.е. Некоторые модули могут быть доступны для телефона Windows).

Домен содержит всю бизнес-логику.

Инфраструктура содержит реализацию репозитория и службы для отправки почты, сохранения файлов и утилит, которые не принадлежат домену. Я собираюсь сделать некоторые из общих сервисов, которые я должен использовать в нескольких доменах (например, отправлять электронную почту), как своего рода API, который я мог бы ссылаться на сохранение кода, реализующего одни и те же вещи в нескольких BC.

Уровень запроса содержит все запросы, кроме GetById, которые мне нужны в репозитории для извлечения объекта. Уровень запроса может запрашивать другие экземпляры персистентности и, вероятно, потребуется изменить некоторые для каждого пользовательского интерфейса.

Wcf или Web Api - это своего рода прикладной уровень, он может принадлежать к инфраструктуре, а не снаружи. Эта служба также устанавливает зависимости, поэтому все пользовательские интерфейсы должны делать запрос - запрашивать информацию и отправлять команды.

Процесс начинается с синих стрелок. Прочтите модель, поскольку она содержит большую часть информации.

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

Итак, вопросы:

Реализует ли такая многоуровневая архитектура так много картографирования или я что-то пропустил?
Рекомендуется ли (или даже умно) использовать службу Wcf для запуска основной логики (это практически моя прикладная служба).
Существуют ли альтернативы Wcf без наличия объектов моего домена в моем уровне пользовательского интерфейса?
Что-то не так с этой реализацией. Любые осенние ямы, на которые нужно обратить внимание?
Есть ли у вас какие-нибудь хорошие примеры, чтобы рекомендовать посмотреть, что может помочь мне понять, как все эти концепции должны работать вместе.

Update: Я прочитал большинство статей сейчас (довольно немного чтения), за исключением платной книги (требуется немного больше времени). Все они - очень хорошие указатели, и способ думать о Wcf больше как адаптер, кажется, является хорошим ответом на вопрос 2. JGauffins работает над его рамками, также очень интересно, если я планирую пойти по этому маршруту.

Однако, как упоминалось в некоторых комментариях ниже, я чувствую, что некоторые из примеров имеют тенденцию рекомендовать или внедрять источники событий и/или команд, шины сообщений и т.д. Для меня сейчас слишком сложно планировать этот уровень масштабирования. Так как многие бизнес-приложения являются "большими" (с точки зрения внутреннего приложения, думаю, max несколько тысяч) число пользователей, работающих с большим набором данных, а не с высококомпетентным доменом в смысле необходимости реализовать событие и команду очереди, часто ассоциированные с CQRS, чтобы справиться с этим.

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

Мне просто нужно справиться с картографированием. Thoe pros перевешивает минусы.
Я верну приложения приложений обратно в инфраструктуру и рассмотрим Wcf как "адаптер"
Я буду использовать объекты команд и отправить в службу приложений. Не загрязнение моего домена объектами домена.
Чтобы сдержать сложность, я стараюсь управлять без события/команды sourcing, автобусы сообщений и т.д. на данный момент.

Кроме того, я просто хотел связать с это сообщение в блоге Udi Dahan о CQRS, я думаю, что такие вещи сохраняют сложность, если только они действительно необходимы.

Ответ 1

Существует компромисс между отображением и слоями. Одна из причин, по которой существуют определенные сопоставления, состоит в том, что соответствующие абстракции недоступны или практически невозможны. В результате часто проще просто явно сопоставить слои, чем пытаться реализовать фреймворк, который отображает сопоставления, но я отвлекаюсь; это зависит от философского обсуждения проблемы.
Служба WCF или WebAPI должна быть очень тонкой. Подумайте об этом как о адаптере в гексагональной архитектуре . Он должен делегировать все услуги приложения. Существует слияние термина service, вызывающего путаницу. В целом, цель WCF или WebAPI - "адаптировать" ваш домен к определенной технологии, такой как HTTP. WCF можно рассматривать как реализацию открытой службы хоста в слове DDD.
Вы упомянули WebAPI, который является альтернативой, если вы хотите HTTP. Самое главное, помните о роли этого адаптирующего слоя. Как вы заявляете, лучше всего, чтобы пользовательский интерфейс зависел от DTO и, как правило, контракт службы, реализованной с WCF или WebAPI или что-то еще. Это упрощает и упрощает реализацию вашего домена, не затрагивая потребителей открытых хост-сервисов.
Вы всегда должны быть в поиске ненужной сложности. Слоизация - это компромисс, и иногда это может быть излишним. Например, в приложении, которое является, в основном, CRUD, нет необходимости много стирать. Кроме того, как указано выше, не думайте, что услуги WCF являются службами приложений. Вместо этого подумайте о них как о адаптерах между транспортной технологией и сервисами приложений. В свою очередь, подумайте о том, что сервисы приложений являются фасад над вашим доменом, независимо от того, реализован ли ваш домен с помощью DDD или метода транзакции script.
То, что действительно помогло мне понять, - это ссылка на гексагональную архитектуру. Таким образом, вы можете просматривать свой домен как находящийся в ядре, и вы обмениваете его вокруг, адаптируя свой домен к инфраструктуре и услугам. Кажется, что вы уже следуете этим принципам. Большой, всесторонний ресурс для всего этого - Внедрение управляемого доменами Vaughn Vernon, в частности глава об архитектуре.

Ответ 2

Влияет ли реализация такой многоуровневой архитектуры, которая действительно связана с большим количеством сопоставлений, или я что-то пропустил?

Да. Дело в том, что это не тот же объект. Это разные представления одного и того же объекта, но специализированные для каждого варианта использования. Модель просмотра содержит логику для обновления GUI, DTO специализирован для передачи (может быть нормализована для облегчения передачи). и т.д. Они могут выглядеть одинаково, но на самом деле это не так.

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

Рекомендуется ли (или даже умнее) использовать службу Wcf для запуска основной логики (это фактически моя Служба приложений)

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

Используя сервер, гораздо легче поддерживать различия версий.

Обратите внимание, что определение службы WCF должно рассматриваться как постоянное при использовании. Любые изменения должны быть определены в новом интерфейсе (например, MyService2).

Существуют ли альтернативы Wcf без наличия объектов моего домена в моем слое пользовательского интерфейса?

Вы можете взглянуть на мои рамки. Начать публикацию: http://blog.gauffin.org/2012/10/writing-decoupled-and-scalable-applications-2/

Что-то не так с этой реализацией.

Не то, что я вижу. Похоже, вы хорошо понимаете концепции и как их следует использовать.

Любые осенние ямы, на которые нужно обратить внимание?

Не пытайтесь лениться с запросами и командами. Не делайте их более универсальными, чтобы соответствовать нескольким прецедентам. Он вернется и укусит вас, когда приложение будет расти. Меньшие классы легче поддерживать.

Есть ли у вас хорошие примеры, чтобы рекомендовать посмотреть, что может помочь мне понять, как все эти концепции должны работать вместе.

Мой связанный пост в блоге и все другие статьи в этой серии.