Java форум JavaTalks

Сразу предупреждаю, что приложения бывают разные, разные уровни у них могут быть, поэтому не вбивайте такую архитектуру себе в голову как догму.
Как правило простые (и не очень) приложения могут быть разбиты на следующие модули (уровни):

Доменная модель - сущности вашей системы, например, если вы разрабатываете "магазин", то ваша доменная модель - это Магазин, Продукт, Покупатель, Пользователь и т.д.
Уровень DAO - в этом уровне реализован доступ к БД или любому другому источнику данных. В классах DAO, например, могут быть такие методы как getUserByUsername(), deleteUser(), etc. Замечу, что на этом уровне нет транзакций, т.к. транзакции как правило принимают участие в бизнес операциях, на этом же уровне ни о какой логике приложения идти речи не может.
Классы этого уровня можно помещать в модуль model, самый нижний модуль, который не зависит от других.
Уровень Сервисов - на этом уровне реализована бизнес логика приложения, управление транзакциями и пр. Пусть не смущает то, что Сервис может повторять методы DAO, эти методы не просто повторяют, они еще и оборачивают в транзакции методы DAO.
В уровень Сервисов может сеттиться несколько DAO для того, чтоб удовлетворить выполнение какой-либо бизнес операции.
Классы этого уровня можно помещать в модуль с именем controller. Этот модуль зависит от модуля model.
Уровень обработки Вида. Если это веб приложение, здесь будут находиться Сервлеты, Контроллеры (Spring MVC), Действия (Struts), как бы там ни было здесь осуществляется обработка запроса и генерация ответа. Однако бизнес логика приложения на этом уровне не присутствует, она делегируется уровню Сервисов. В идеале, если у нас был веб интерфейс, но мы возжелали доступ к нашему приложению еще и по средствам веб сервисов, тогда мы только добавим еще одну реализацию данного уровня и никакого дублирования кода у нас не будет, ибо уровень Сервисов останется тот же.
Классы этого уровня можно помещать в модули по типу view-controller-springmvc, vew-controller-ws. Как правило этот модуль зависит от уровней model и controller.
Вид. Ну это обычный уровень работы с интерфейсом, здесь могут быть размещены, к примеру, JSP страницы.
Этот модуль можно назвать view, зависеть он будет от модуля view-controller, иногда и от model, если он может работать с объектами доменной модели (в идеале он должен работать только с DTO, которые находятся в view-controller).

Здесь есть пример: JT Webinar: Разработка Web-приложения в среде IntelliJ IDEA.
Правда он маленький.
_________________
JTalks Open Source Project, JT Webinars, JT Interview

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

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

Почему же тогда такое расслоение описано выше? Ну во-первых, я тогда еще много чего не понимал =) Во-вторых, такое разбиение на слои очень популярно - заметьте, что все вокруг говорят "в классах доменной модели не должно быть логики, не-долж-но!". Это так называемая анемичная доменная модель. Почему так получилось? Мое предположение, навеянное неким Chris Richardson, что эта мода пошла от EJB, т.к. в EJB 2 этот подход был всегда используем (не знаю насчет EJB 3), возможно Sun в те годы развернуло PR-компанию по тому, как должны строиться приложения. Но не будем философствовать, точно я все одно не знаю. Итак, каковы же аналоги?
Есть один J2EE шаблон проектирования, так называемый Domain Model, впервые описанный Мартином Фаулером (Martin Fowler). Говорит он о том, что бизнес логика должна лежать в классах доменной модели. Это не значит, что она должна лежать прям в ваших сущностях, которые вы сохраняете в БД, доменная модель - это нечто большее, это собственно проекция предметной области на классы, таким образом если мы говорим про какую-нибудь аэро-службу, которая может бронировать билет, то конкретно для такой задачи можно создать какой-нибудь FlightBooker, который будет именно этим и занят, и при этом вполне можно так себе давать ему доступ к DAO, например, вот так:

ИМХО FlightBooker и есть типичный представитель уровня сервисов (ты правильно выше написал, что уровень сервисов содержит бизнес-логику).
А все описанные проблемы с переусложнением, дублированием, сложночитаемостью и процедурному стилю - это проблема авторов системы и присуща не только J2EE, но и любому приложению, где не прилагаются своевременные усилия по рефакторингу.
EJB2.x отлично подходят для организации сервис-фасадов. Это довольно популярная практика - предоставлять доступ к сервисам системы через SLSB-фасад.
_________________

Может быть сказывается мой опыт работы разработчиком БД, но почему не рассматривается вариант занесения бизнес-логики в саму БД?
В этом случае все сложные вычисления ложатся на оптимизированное ядро СУБД. Да и надежность транзакций повышается значительно.

это уже будет SOA

Все в конечном итоге зависит от конкретного случая. Если такая архитектура покажется слишком сложной и отягощающей, почему бы не сделать так, как будет удобней и проще?
Но. Какова бы не была "1 маленькая логика", если мы говорим про доменную логику, она должна быть реализована следуя шаблону Доменная Модель. Иначе эту "маленькую логику" нельзя будет никак переиспользовать. Хотя и это бывает лишним, так что опять же - it depends.

Я тоже начитавшись Фаулера, после того как перешел с PHP на Java, был глубоко шокирован тем, что большинство джавистов не понимают, что они только думают, что пишут в ООП парадигме, а на деле их код, реализующий анемичную модель является чисто процедурным.

Уверен, что это относится не ко всем и существуют и нормально спроектированные проекты с применением Domain Model и Domain Driven Design.

С удовольствием устроюсь на работу в такой проект Smile

_________________
"Счастливые" нулевые. "Кровавое Воскресенье"