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 покажет что сущность можно разбить на несколько. Накой это нужно, если по логике предметной области она является монолитной?

vimbaВсё нужно считать нужно потому что по другому с людьми которым Фаулер выел мозг разговаривать нельзя
Что ж ты такой нервный. Праздники не удались? Или с похмелья. Если внимательно перечитать то что написано выше, то можно заметить, что Фаулер лишь упоминается в том контексте, что предоставляет наиболее полную классификацию паттернов, которую удобно использовать.
Нигде выше я не говороил что Фаулер это последняя инстанция и нужно строго следовать его рекомендациями. А ты ни на одно сообщение по теме не ответил. Только психуешь из-за недостатка аргументации.

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

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

vimbaТак как бы действует поговорка в своём отечестве пророков нет,

Ты пророк или про кого эта цитата не в тему?

vimbaони мнение неосилятора JEE Фаулера, ценят больше чем мнения людей из SUN, Oracle, IBM создавших платформу JEE на основе десятилетиями накопленного опыта разработки и главное поддержки интерпрайз систем.
Женская логика - аппелировать к тому что к теме вообще отношения не имеет.

vimbaСудя по длине твоих постов нервничаешь именно ты, так что остынь.
Ты меня веселишь своей психушкой. Вот и пишу.

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

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

vimbaА тут и не нужно ничего более, Rich это наличие сложных классов слабосвязанных внутри, это высказывание легко подсчитать математически и трудно оспорить. Всё остальное что я могу сказать про Rich это как-раз таки будет флудом, тут просто как Станиславский можно сказать неверю. Сейчас рефактрю проект в стиле рич, но весь тот негатив который я могу про него написать легко оспорить, мол ну этот то проект точно дураки писали, вот писал бы я получилось лучше.
У тебя ещё и с логикой плохо. Если проект написан плохо, это не значит что всё что в нем используется тоже плохо и делать нужно всё наоборот. Это ещё у Крылова в басне было.

vimbaВот уже пошла болтология, поэтому я и писал выше что конкретные цифры лучше и без них лучше вообще ни о чем не разговаривать.
Смысл тебе показывать цифры, если ты ни в терминологии не ориентируешься, ни читать не хочешь то о чем тебе пишут.
Rich model это не та где вся логика напихана в сущности, это та, которая "не Anemic", в которой в сущностях вообще нет логики.
Если у тебя проект, где в сущностях реализовано вообще всё, да ещё и с "Bad Cohesion", это не значит что любая Rich модель выглядит именно так. Rich Model даже не исключает Transaction Script и другие паттерны. Они вместе могут чудесно сосуществовать.