Сервис-ориентированная архитектура и Управляемый Доменом Дизайн

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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