Структура приложений

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

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

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

public class FlightBooker {
  void book(BookInfo bookInfo, FlightDao flightDao) {...}
}

Это не значит, что мы просто вырезаем наш уровень служб, он так и остается жить, просто теперь вместо того, чтоб выполнять логику приложения, он будет дергать методы других классов - это и есть обязанности Фасада (уровень служб также называют Service Facade). Причем он по-прежнему будет управлять транзакциями.
А также, не бойтесь помещать логику в сущности вашей системы, если эта логика относится к этой сущности, то почему бы и нет? Ведь, классы - это данные+поведение. Главное - знайте меру ;)
Это вроде бы все, что я хотел рассказать сегодня.
Рекомендуемая литература:
- Patterns of Enterprise Application Architecture
- POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks

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

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

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

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

Ну, хорошо. И что? Это что-то принципиально другое?

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

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

Даже если узел - маленькое приложение, реализующее 1 логику?

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

И "в крупных и сложных проектах у него есть большой недостаток". Вот мне и интересно, почему так популярны "крупные и сложные", почему не "много мелких и простых", как предлагается в SOA.

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

1) логика в БД сложно поддается юнит-тестированию
2) приводит к привязке к вендору
3) ее очень сложно поддерживать
4) очень дорого масштабировать (особенно если мы говорим об Oracle)
Тем не менее, некоторые части все же надо делать в БД.

- Надежность транзакций идеально контроллируется JTA. К тому же транзакции нужны не только на уровне чтения/записи данных, но и на транспортном уровне.
- оптимизированное ядро СУБД не оптимизировано для проведения вычислений. Гриды (Hadoop, Data Synapse) с этой задачей справляются намного лучше. Инструменты нужно использовать для того, для чего они предназначены.

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

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

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

Да всё Мы понимаем, однако кушать то же хочеться, а за хореаграфию почему-то никто не доплачивает, а платят за фичи. И когда задача сводиться к тому что у Маши было четыре яблока она продала два яблока Пети и нужно посчитать прибыль с учетом затрат на хранение яблок в холодильнике и налога с продаж то Data Driven Design с анемичной моделью это серебрянная пуля, так как с учетом развитости java фреймворков позволяет лабать код быстро и добавлять такие фичи тоннами оперируя стандартными паттеренами сущность/ДАО/сервис/MVC не особо напрягая свой мозг. И будьте уверены что ваше ООП честолюбие найдет где себя проявить и при таком топорном подходе, ибо модель еще нужно отобразить, а шаблоны корпаративных приложений скушны и банальны, то ли дело когда дойдет до отображение модели вот там действительно придется включать мозг когда потребуется чуть-чуть больше чем CRUD.

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


Я бы просто занялся философией. Ты негодуешь относительно того, что мы не признаем факта что булка хлеба может сама себя испечь, погрузить в грузовик, выгрузить на прилавок, продать или еще хуже того сама себя съесть, да я против подхода наделить груду муки поведением, всегда есть те кто осуществляет действия(СЕРВИСЫ) и что-то над чем осуществляют действия(СУЩНОСТИ или ОБЪЕКТЫ-ЗНАЧЕНИЯ). Если ты против анемичной булки то ты автоматом против того, кто хочет съесть не порезав ножом а просто поломав руками(или другим не предусмотренным в булке способом, и не варвары это вовсе может у них просто ножа нет), а всевозможные способы поедания хлеба в саму булку ты никогда не заложишь.

Кхм... :) может я мало чего понимаю, не хотелось бы оказаться в глупом положении высказав своё мнение, когда спорят более опытные коллеги, но у меня последние два дня жажда троллинга побеждает здравый смысл, поэтому не обессудьте если глупость сморожу :)
Я думаю Староверъ имел ввиду правило рефакторинга - логика и данные с которыми она работает должны находиться в одном месте (классе). При подходе с сервисами, у программиста возникает очень большое желание выносить логику которая относится непосредственно к сущности, в логику сервисного слоя (потому что сущность то анемичная) - и получается, что это одно из основных правил рефакторинга легко нарушить. И если это сделать у нас получается что кишки логики которая должна быть спрятана в классе, вывернуты наружу. Это происходит так как сама система разбиения на сервисы и анемичные сущности подталкивает к написанию кода в таком стиле.