Service Layer это Transaction Script в каталоге Фаулера.
http://martinfowler.com/eaaCatalog/transactionScript.html
Очень рекомендую прочесть Enterprise Patterns, хотя бы в переводе.

Service Layer описывает бизнес-процесс и является частью Domain Model.
Он реализует такие методы, которые не могут находится в Domain Entity по той причине, что не реализуют поведение этой Entity.

Правильное распределение методов между Service Layer и Domain Entity достаточно сложный вопрос, так как решение лежит по середине между двумя крайностями.
Крайность Anemic Domain Model заключается в том что сущности не содержат поведения вообще. Из-за чего его сложно переиспользовать.
Крайность Rich Domain Model заключается в том, что сущности содержает в себе слишком много поведения, которое к ним не относится и которое тянет за собой кучу интеграционных зависимостей.

/topic/881080

Свежая тема, много интересного можно подчерпнуть
http://rsdn.ru/forum/design/4996858

vimbaСтранный вывод.

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

vimbaКак раз таки если сущность не содержит поведения то она легко переиспользуется

Путаете мягкое с теплым. Сущность плохо переиспользуется не когда у неё есть поведение, а когда у неё есть зависимости, которые нельзя использовать в новом контексте.
Я же говорю о переиспользовании логики. Вообще в плоских серверных приложениях такое не часто нужно, там каждая транзакция по-своему уникально и слои все легко прошиваются как вдоль так и поперек. А вот в толстом GUI, или когда у проекта 100500 интеграций, или в других не типичных аналогах Pet Store, и всплывают недостатки Anemic.
Вот у меня, например, сейчас ситуация, когда нужно одни и те же вычисления делать при валидации и при автозаполнении значений. Логика не тривиальная. Но не писать же её два раза. Слои валидации и UI вообще минимально пересекаются, было бы глупо дергать валидацию непонятно покакому событию чтобы с помощью неё реализовать автозаполнение. Поэтому логика максимально выносится в сущности.
Ааа, нет. У меня даже 3й слой есть, которому нужны те же вычисления - серверная 3rd party интеграция. Она тоже ни к UI ни к валидации отношения не имеет. И единственная альтернатива Rich model это "архитектура на хелперах". Делается отдельный класс с логикой для сущности, вот только логика становится в два раза сложнее, потому что находится снаружи.


vimba, вплоть до того что особо храбрыебезрассудные отдают из вебсервисов сразу доменные сущности без введения понятия DTO.
Ну, я так делаю. И что самое удивительное - логика этому не мешает. Потому что сериализуется только состояние. Наличие или отсутствие логики здесь так же перпендекулярно.
A DTO - большое зло в том виде в котором его предлагают делать по-умолчанию - тупо копировать модель.

vimbaЧем больше сущность содержит поведения тем меньше вероятность её переиспользовать где-то либо ещё

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

vimba, так как работа с жирной моделью напоминает распутывание новогодней гирлянды, слишком уж много приходится держать в голове вариантов использования одной энтити.
Anemic Model это первая ступень к упрощению. Но это аналогично разрубанию гордиева узла. Хорошо что вы до этого дошли. Но нужно двигаться дальше - вторая ступень это возвращение к Rich Model, но правильной, так же минимизирую связи как и в Anemic, но максимально переиспользуя логику как в Rich.

забыл никИ в какой слой этот хелпер засовывать? Я что-то непонимаю как это поможет
Ну, это тривиальный дизайн. Не важно куда его засовывать, потому что так не стоит делать вообще. Вот сделали сущность без логики. И Transaction Script, в котором вся логика. И вдруг что-то из Transaction Script нам понадобилось где-то ещё?
Как делает Anemic апологет? Создаёт Helper, выносит туда переиспользуемую логику, и использует её как внутри Transaction Script, так и в других слоях. А как нужно было сделать? Добавить логику в сущность и пользоваться ей везде, где сущность доступна.

tumblerrrА что мешает делать не тупо "как в книге" или Anemic или Rich.
А там где надо добавлять логику в сущность?
Ну будет у вас в некоторых сущностях логика, кому от этого плохо-то будет?
Ничего не мешает. Не теряйте нити разговора. Я выше объяснил.

vimbaActive Record часто ассоциирует с Rich потому что он является необходимым условием для посторения rich, без него толстая модель не дееспособна в принципе.
Это не так. Вы делаете слишком безапеляционные заявления. Проблема в Rich модели на сервере в том что сущности тянут за собой зависимости от слоя persistence. И Фаулер предлагает решать эту проблему через паттерн Repository. Repository для каждого контекста может быть реальзован по-разному. Где-то читает из базы, где-то из локального кеша, где-то удаленным вызовом на сервер. Cама же организация Rich Domain Model к Active Record отношения не имеет. Active Record это просто способ организации доступа к данным.

vimbaЯ не вижу чем переиспользование всякого хелпера или валидатора отличается от переиспользования метода находящегося в самой сущности.

Бывает. Хелпер имеет набор параметров - не все параметры могут быть доступны в текущем контексте. Хелпер оперирует публичным контрактом объекта, но, обычно при этом зависит и от его внутренней реализации. Изменение которой влечет за собой каскадные изменения в хелперах. Внутри одного класса рефакторить и контролировать логику проще. Сам код тупо проще. Уже писал об этом выше.

vimbaВот преимущество хелпера вижу, код становится более высокакачественным,

Ни о чем. Нет такой характеристики кода - "высококачественный". "Переиспользуеймый", "слабо связаный" и т.п. - это характеристики кода.

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

Нет такого понятия "типичной жирной сущности". Как я уже говорил выше, в Rich модели самое сложное это правильно распределять логику между классами (не только сущностями), чтобы связанность была минимальной как и в Anemic, но при этом логика была максимально переиспользуема, чего нет в Anemic.

vimbaНа всё остальное отвечать просто не хочется, бред вызванный ООП головного мозга,

Вы мало того что терминологией не владете так ещё и на личности переходите. Вы девушка? У девушек как аргументация заканчивается так сразу эмоции.

vimbaФаулера нужно меньше читать,

Правильно! Меньше книг - больше говнокода.

vimbaа больше изучать практики доминирующие на платформе которой программируешь и настощих классиков ООП.

Anemic Domain Model это доминирующая практика в Java? А Фаулер фальшивый классик?

vimbaКонечно сам Фаулер мужик то неплохой,

Знакомы лично?

vimbaон даже одну книжку бестселлер написал Рефакторинг
Вы не верно понимаете термин "бестселлер". Потому что он у Фаулера не один.

vimba, но вот его толкователи уже порядком достали.
Бедный.

vimbaВы уже посчитали LCOM4 на своих жирных сущностях?

Да, уже убежал в слезах за линейкой.

vimbaВы уже посчитали LCOM4 на своих жирных сущностях? Как посчитаете возвращайтесь продолжим разговор предметно оперируя цифрами, бла бла бла ни о чем, меня как-то мало интересует.
Любопытно, на кой хер мерять LOCM4 на сущностях модели предметной области, если в них набор свойств диктуется самой предметной областью, а методы помещаются исключительно в соответствии с этим набором свойств?
То есть, допустим, LCOM4 покажет что сущность можно разбить на несколько. Накой это нужно, если по логике предметной области она является монолитной?