Подтвердить что ты не робот

Сервисно-ориентированная архитектура и управление доменом

Я всегда разрабатывал код в виде 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?

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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

[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", который берет объект заказа и пытается обновить его в новом сеансе?

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

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

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

Ответ 2

Важнейшие вещи, связанные с проектированием, основанным на домене, - это идеи большой картины:

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

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

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

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

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

Ответ 3

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

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

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

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