romashov90Вот разработали Protobuf-Converter который преобразует Domain Object в Google Protobuf Message.

И нигде не написано зачем именно вы это сделали.

no56892romashov90,
Domain objects aka entity как бы не должны вылезать за пределы сервис лэйера.
Очень странное заявление. Первый раз такое слышу.

no56892Уменьшает связанность.
Ценой раздувания кода делающего одно и то же. Ограничивает область переиспользования бизнес-логики. Если только у вас 100% anemic domain model.

no56892Фронтэнд (контроллер) не зависит от структуры БД и от шняги JPA'евской.
В чем такая зависимость проявляется?

no56892У Вас >= 2 версий АПИ, что будете делать?
Зависит от протокола. Обычно, это просто обратная совместимость. В более сложных случаях фасады и адаптеры.

no56892>>Ограничивает область переиспользования бизнес-логики
Как это проявляется?
Ну, вот так, что в Rich Domain Model у тебя в сущностях куча поведения. И это поведение тебе нужно на всех слоях приложения.
Например, вычислимые состояния. То есть, некоторое свойство, которое вычисляется из зависимостей и в БД не хранится.
И так случается что от этой логики у тебя зависит и лампочка на UI и способ сохранения в БД.
В случае с Anemic, ты эту логику отдираешь от объекта и пихаешь в DomainObjectUtils убивая инкапсуляцию. Там выходит тупо жирный код оперирующей массой свойств, вместо простого метода класса DomainObject, оперирующего полями.

no56892В том, что есть war например с контроллерами, и jar с сервисами, если вы возвращаете/передаете параметром в сервис домэин обжект, то надо в зависимости к war проекту добавлять jpa -api. А нафига?
Это какая-то ересь. war и ejb-jar это JEE модули. А JPA это часть JEE спецификации. JPA API тебе предоставляет контейнер.

no56892Фаулер ИМХО теоретик жуткий

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

no56892, это типа он говорит бэд практис, т.к. данные отделены от их обработки, возьмем валидацию, например, длинны пароля, которая настраивается динамически, Вы будете инжектить коннект к базе в ентити User что бы в нем проверить?
Тут всё просто. Если метод манипулирует полями класса, то он должен быть в этом классе. Проблема Anemic Model в том что таких методов вообще нет.


no56892Я вообще вот о чем:


В контроллере подключаем service-api. То есть:
Браузер <-- (Json/rawdata) --> Контроллер <--JSonObject/Dto/просто параметры если простая структура--> Сервис-апи
Да, понятно. DTO это про Transfer, когда несериализуемая сущность превращается в сериализуемую для удаленной передачи. Использовать DTO внутри одной JVM это слегка за гранью моего понимания. Вопрос о том что мешает сериализовать сущности в JSON остается неотвеченным.

no56892Дак никто не мешает сделать это методом ентити или сервиса.

Мешает то что у тебя нет сущности в web модуле. Только DTO. Поэтому подобная логика у тебя реализована в сервисе, который не делает ничего полезного, кроме как оперирует методами DTO?

no56892Народ делает war проект, подключает service-api и все, зачем им нужен jpa-api? У них есть их сервлеты, фильтры и апи сервисов.
Ты повторяешь свой вопрос. Я могу повторить свой ответ.

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

Ну, о том и речь.

no56892Ну так все таки, что делать с валидацией пароля?
За валидацию сущностей отвечает слой валидации. Если его надо конфигурировать, он конфигурируется. Валидация это вполне специфичная и конкретная задача. Я же говорю о методах сильно связанных с предметной областью.

no56892Отделить апи от реализации

А смысл? Это API является независимым от реализации? Или реализация является не зависимой от API, которое она реализует? Бред же. API не функционирует без реализации, а реализация вообще железными гвоздями намертво прибита к API, который она реализует.
Возможно речь идёт о "фасаде"? Рано вы Фаулера сожгли-то.

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

no56892она не должна смотреть наружу вообще никак.
Если у тебя вся бизнес-логика умещается в Transaction Script aka Service, то тебе просто повезло. А вот у меня в ERP были методы которые нужно использовать в куче слоёв:
GUI
TransactionScript
Data Replication
Data Conversion
И наличие методов в сущностях здорово повышает переиспользование и невероятно упрощает код. А делать все эти слои зависимыми от TransactionScript это слегка за гранью.

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