Сервис-ориентированная архитектура и доменно-ориентированный дизайн

Question

Я всегда разрабатывал код в стиле SOA. В этом году я пытался сделать больше DDD, но у меня постоянно возникает ощущение, что я не получаю это. На работе наши системы сбалансированы по нагрузке и разработаны так, чтобы не иметь состояния. Архитектура:

Веб-сайт

=== Физический уровень ==

Основное обслуживание

== Физический уровень ==

Сервер 1 / Сервис 2 / Сервис 3 / Сервис 4

Только Сервер 1, Служба 2, Служба 3 и Служба 4 могут общаться с базой данных, и Основная Служба вызывает правильную службу на основе заказанных продуктов. Каждый физический уровень также сбалансирован по нагрузке.

Теперь, когда я разрабатываю новый сервис, я стараюсь использовать DDD в этом сервисе, даже если он не совсем подходит.

Я использую хорошие принципы DDD, такие как сущности, типы значений, репозитории, агрегаты, фабрики и т. Д.

Я даже пытался использовать ORM, но они просто не вписываются в архитектуру без состояния. Я знаю, что есть способы обойти это, например, использовать IStatelessSession вместо ISession с NHibernate. Однако ORM просто чувствует, что они не вписываются в архитектуру без сохранения состояния.

Я заметил, что на самом деле использую только некоторые концепции и шаблоны, которым научил меня DDD, но общая архитектура все еще остается SOA.

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

Как я уже сказал, может быть, я просто не понимаю DDD или, может быть, я слишком много анализирую свои проекты? Может быть, используя шаблоны и концепции, DDD научил меня использовать DDD? Не уверен, есть ли на самом деле вопрос к этому посту, но у меня возникло больше мыслей, когда я пытался выяснить, в какой степени DDD вписывается в общую систему и насколько она масштабируема. Правда в том, что я даже не знаю, что такое DDD?

Answer 1

Я думаю, что распространенным заблуждением является то, что SOA и DDD - это два противоречивых стиля.

ИМО, это две концепции, которые прекрасно работают вместе; Вы создаете модель домена, которая инкапсулирует концепции вашего домена, и открываете точки входа в эту модель с помощью сервисов.

Я также не вижу, в чем проблема с ORM и сервисами, вы можете легко использовать сеанс / ух для каждого вызова сервиса. Просто смоделируйте свои сервисные операции как команды атомарного домена.

Наивный пример:

[WebMethod]
void RenameCustomer(int customerId,string newName)
{
    using(var uow = UoW.Begin())
    {
        var customerRepo = new CustomerRepo(uow);
        var customer = customerRepo.FindById(customerId);
        customer.Rename(newName);
        uow.Commit();
    }
}

Может быть, проблема, с которой вы сталкиваетесь, заключается в том, что вы создаете такие службы, как "UpdateOrder", который принимает сущность заказа и пытается обновить ее в новом сеансе?

Я стараюсь избегать такого рода сервисов и вместо этого разбиваю их на более мелкие атомарные команды.

Каждая команда может быть представлена ​​как операция, или у вас может быть одна служебная операция, которая получает группы команд и затем делегирует их командам-обработчикам.

ИМО, таким образом, вы сможете лучше раскрыть свои намерения.

Answer 2

Самыми важными моментами в доменно-управляемом дизайне являются общие идеи:

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

Они широко применимы и являются наиболее ценными.

Существует множество шаблонных шаблонов о фабриках, сервисах, репозиториях, агрегатах и ​​т. Д., Я принимаю это как совет от одного опытного разработчика другому, а не как Евангелие, потому что многое из этого может варьироваться в зависимости от язык и рамки, которые вы используете. Имхо они склонны переоценивать, потому что такие программисты, как мы, ориентированы на детали, и мы зацикливаемся на таких вещах. Там тоже есть ценные вещи, но их нужно держать в перспективе. Поэтому, возможно, что-то из этого не имеет к вам никакого отношения, или это может на вас повлиять, когда вы с ним работаете.

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

В частности, в отношении SOA я разработал приложения, которые откладывают все свое состояние до базы данных, в которых используются доменные объекты, не учитывающие постоянство. Написание тестов для сервисов, которые должны смоделировать даос и возвращать материал назад, - это рутинная работа, чем больше логики я могу поместить в доменные объекты, тем меньше мне приходится связываться с имитациями в моих сервисах, поэтому мне больше нравится этот подход.

Answer 3

В DDD введены некоторые концепции, которые действительно могут сбить вас с толку при создании SOA.

Я должен полностью согласиться с другим ответом , что SOA-сервисы предоставляют операции, которые действуют как атомарные команды. Я считаю, что очень чистый SOA использует сообщения вместо сущностей. Затем реализация службы будет использовать модель домена для фактического выполнения операции.

Однако в DDD существует концепция, которая называется «служба домена». Это немного отличается от службы приложений. Обычно «служба домена» разработана на том же вездесущем языке, что и остальная часть модели домена, и представляет бизнес-логику, которая не совсем вписывается в сущность или значение.

Службу домена не следует путать со службой приложения. Фактически, прикладная служба вполне может быть реализована так, что она использует доменную службу. В конце концов, сервисы приложений могут полностью инкапсулировать модель домена в SOA.

Answer 4

Я действительно очень поздно в этом, но я хотел бы добавить следующее в очень хорошие ответы всех остальных.

• DDD не конфликтует с SOA . Вместо этого DDD может помочь вам поддерживать лучшую сервис-ориентированную архитектуру. SOA продвигает концепцию сервисов, так что вы можете определить лучшие границы (о, граница контекста также является концепцией DDD!) Между вашими системами и улучшить их понимание.
• DDD не касается применения набора шаблонов (например, хранилище, сущности и т. Д.). DDD в основном касается попыток смоделировать ваше программное обеспечение , чтобы все концепции (т. Е. Классы в случае объектно-ориентированного программирования) напрямую соответствовали концепциям бизнеса.

Вам также следует проверить это видео (особенно последние 5 минут), где Эрик Эванс обсуждает именно эту тему.

---

Я даже пытался использовать ORM, но они просто не подходят архитектура без гражданства.

У меня нет ссылок, чтобы это подтвердить. Тем не менее, вы правы, ORM не очень хорошо подходят и для DDD. Это потому, что они пытаются преодолеть несоответствие объектно-реляционного импеданса , но неверным способом. Они принуждают программное обеспечение к модели анемичной области , где классы оказываются «простыми носителями данных».

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

В видео, которое я привел выше, вы также можете найти Эрика, объясняющего, что концепции DDD могут «сломаться» в очень крупномасштабных системах. Например, представьте систему розничной торговли, где каждый заказ представляет собой совокупность, содержащую потенциально тысячи позиций заказа. Если вы хотите рассчитать общую сумму заказа строго в соответствии с DDD, вам придется загрузить все элементы заказа в память, что будет крайне неэффективно по сравнению с использованием вашей системы хранения (например, с умным оператором SQL). Так что об этом компромиссе нужно всегда помнить, DDD - это не серебряная пуля.

Как я уже сказал, может быть, я просто не понимаю DDD или, может быть, я закончил анализируя мои проекты?

Извините, но мне придется еще раз процитировать Эрика Эванса. Как он сказал, DDD не для перфекционистов, что означает, что могут быть случаи, когда идеального дизайна не существует, и вам, возможно, придется искать решение, которое хуже с точки зрения моделирования. Чтобы узнать больше об этом, вы можете проверить эту статью .