Как реализовать поддерживаемое и слабо связанное приложение с использованием DDD и SRP?
причина этого вопроса в том, что мне было интересно, как сшить все эти разные концепции вместе. Есть много примеров и обсуждений, например, DDD, инъекции зависимостей, CQRS, SOA, MVC, но не так много примеров о том, как собрать их все вместе гибким способом.
моя цель:
- разработка модулей, которые с небольшим количеством или без модификации могут стоять самостоятельно
- изменение или переработка пользовательского интерфейса должны быть такими легко, как это возможно (т. е. пользовательский интерфейс должен делать как можно меньше, и быть"глупым"
- описанные модели и принципы
чтобы было проще задать конкретный вопрос, основная архитектура теперь выглядит так:
в примере показано, как добавить записки на сотрудника. Управление персоналом-это один ограниченный контекст. Сотрудник имеет несколько свойств, среди которых ICollection<Note>.
связанный контекст в моем понимании логика - это место для разделения кода. Каждый год до н. э.-это модуль. Большую часть времени я нахожу, что каждый из них может гарантировать свой собственный пользовательский интерфейс, если это необходимо (т. е. некоторые модули могут быть доступны для Windows phone).
Домен содержит всю бизнес-логику.
инфраструктура содержит реализацию репозитория и службы для отправки почты, сохранения файлов и утилит, которые не принадлежат домену. Я думаю сделать что-то общее. сервис feautures, который я должен использовать в нескольких доменах (например, отправить электронную почту) как своего рода API, на который я мог бы ссылаться, чтобы сохранить некоторый код, реализующий те же самые вещи в нескольких BC.
запрос слое содержит все запросы, кроме GetById, которые мне нужны в репозитории для извлечения объекта. Слой запросов может запрашивать другие экземпляры сохраняемости и, вероятно, потребуется изменить некоторые для каждого пользовательского интерфейса.
Wcf или Web Api-это своего рода мой уровень приложения, он может принадлежать инфраструктуре, а не внешнему миру. Эта служба также устанавливает зависимости, поэтому все, что нужно сделать пользовательскому интерфейсу, - это запросить информацию и отправить команды.
процесс начинается с синими стрелками. Прочитайте модель, так как она содержит большую часть информации.
на шаге 1 EmployeeDto в этом примере-это только некоторые свойства сотрудника, чтобы показать информацию пользователя о сотруднике, на котором им нужно сделать заметку (например, заметку о новом опыте или что-то еще вроде этого.)
Итак, вопросы:
- действительно ли реализация многоуровневой архитектуры, как это, включает в себя так много отображения, или я что-то пропустил?
- рекомендуется ли (или даже умно) использовать службу Wcf для запуска основной логики, как это (это практически моя служба приложений)
- существуют ли альтернативы Wcf без наличия объектов домена в моем слое пользовательского интерфейса?
что-то не так с эта реализация. Любое падение ямы высматривать?
есть ли у вас хорошие примеры, чтобы рекомендовать смотреть, что может помочь мне понять, как все эти концепции должны работать вместе.
обновление: Я прочитал большинство статей сейчас (довольно много чтения), за исключением платной книги (требуется немного больше времени). Все они очень хорошие указатели, и способ мышления Wcf больше как адаптер кажется хорошим ответом на вопрос 2. Работа JGauffins над его структурой также очень интересна, если я планирую пойти по этому маршруту.
однако, как упоминалось в некоторых комментариях ниже, я чувствую, что некоторые примеры имеют тенденцию рекомендовать или реализовывать источник событий и/или команд, шины сообщений и так далее. Для меня это перебор планировать этот уровень масштабирования прямо сейчас. Как и многие бизнес-приложения, это "большое" (с точки зрения внутреннего приложения, подумайте, максимум несколько тысяч) количество пользователей, работающих над большим набором данных, а не очень совместный домен в смысле необходимости реализации очередей событий и команд, часто ассоциированных с CQRS, чтобы справиться с этим.
основываясь на ответах ниже, подход, с которого я начну, будет основан на модели выше и таких ответах:
Мне просто нужно справиться с отображением. Те плюсы перевешивают минусы.
я потяну службы приложений обратно в инфраструктуру и рассмотрим Wcf как "адаптер"
Я буду использовать командные объекты и отправлять в службу приложений. Не загрязнение моего домена объектами домена.
чтобы снизить сложность, я пытаюсь управлять без события / команды поиск, автобусы, сообщение и т. д. Сейчас.
кроме того, я просто хотел связать с это сообщение в блоге Уди Дахана о CQRS, я думаю, что такие вещи, как это снижает сложность, если они действительно не нужны.
2 ответов
существует компромисс между отображением и слоями. Одна из причин существования определенных отображений заключается в том, что соответствующие абстракции недоступны или невозможны. В результате часто проще просто явно отображать между слоями, чем пытаться реализовать структуру, которая выводит сопоставления, но я отвлекаюсь; это зависит от философского обсуждения проблемы.
служба WCF или WebAPI должна быть очень тонкой. Подумайте об этом как о адаптере в a гексагональной архитектуры. Он должен делегировать все службе приложений. Существует смешение термина "служение", которое вызывает путаницу. В целом, целью WCF или WebAPI является "адаптация" вашего домена к определенной технологии, такой как HTTP. WCF можно рассматривать как реализацию открыть узел службы на языке DDD.
вы упомянули WebAPI, который является альтернативой, если вы хотите HTTP. Самое главное, осознавать роль этого адаптация слоя. Как вы заявляете, лучше всего, чтобы пользовательский интерфейс зависел от DTOs и вообще контракта службы, реализованной с WCF или WebAPI или чем-либо еще. Это упрощает работу и позволяет варьировать реализацию вашего домена, не затрагивая потребителей открытых хост-сервисов.
вы всегда должны быть в поиске ненужной сложности. Расслоение-это компромисс, и иногда это может быть излишним. Например, в приложении, которое в основном является CRUD, нет нужно много наслоить. Кроме того, как указано выше, не думайте о службах WCF как о службах приложений. Вместо этого думайте о них как о адаптерах между транспортной технологией и службами приложений. В свою очередь, подумайте о службах приложений как о фасаде над вашим доменом, независимо от того, реализован ли ваш домен с помощью DDD или сценария транзакций.
что действительно помогло мне понять, это ссылочная статья о гексагональной архитектуре. Именно такой образ, вы можете рассматривать свой домен как ядро, и вы накладываете вокруг него слой, адаптируя свой домен к инфраструктуре и сервисам. То, что у вас есть, похоже, уже следует этим принципам. Отличный, глубокий ресурс для всего этого -Реализация Доменного Дизайна вон Вернон, в частности, глава об архитектуре.
действительно ли реализация многоуровневой архитектуры, как это, включает в себя так много отображения, или я что-то пропустил?
да. Дело в том, что это не один и тот же объект. Это разные представления одного и того же объекта, но специализированных для каждого варианта использования. Модель представления содержит логику для обновления GUI, DTO специализируется на передаче (может нормализоваться для облегчения передачи). так далее. так далее. Они могут выглядеть одинаково, но на самом деле это не так.--3-->
вы конечно, можно было бы попытаться поместить все адаптации в один класс, но с этим было бы не очень весело работать, когда ваше приложение растет.
рекомендуется ли (или даже умно) использовать службу Wcf для запуска основной логики, как это (это практически моя служба приложений)
вам нужен какой-то сетевой уровень. Я бы не позволил всем клиентским приложениям касаться моей базы данных. Это создаст кошмар обслуживания, если вы испортите схему базы данных (если некоторые из клиентов все еще запускают старую версию).
С помощью сервера гораздо проще поддерживать различия версий.
обратите внимание, что определение службы WCF должно рассматриваться как константа после использования. Любые изменения должны быть определены в новом интерфейсе (например,MyService2).
существуют ли альтернативы Wcf без наличия объектов домена в моем слое пользовательского интерфейса?
вы можете взглянуть на мою структуру. Начать пост: http://blog.gauffin.org/2012/10/writing-decoupled-and-scalable-applications-2/
есть ли что-то неправильное в этой реализации.
не то, что я вижу. Похоже, вы довольно хорошо понимаете концепции и то, как их следует использовать.
любое падение ямы высматривать?
Не пытайтесь лениться с запросами и командами. Не делайте их немного более общими, чтобы соответствовать нескольким использованию случаи. Он вернется и укусит вас, когда приложение вырастет. Меньшие классы легче поддерживать.
есть ли у вас хорошие примеры, чтобы рекомендовать смотреть на это, может помочь мне понять, как все эти концепции должны работать вместе.
мой связан блоге и все другие статьи в этой серии.