Как правильно обрабатывать запросы в бизнес-приложении?

Question

[Denis Kostousov]

Назрел вопрос.
По моему представлению, обработка запроса в бизнес-приложении разбивается на шаги:
1. синтаксическая проверка данных запроса,
2. проверка существования упомянутых в запросе объектов,
3. загрузка этих объектов из разного рода хранилищ,
4. проверка согласованности этих объектов (например, Заказ принадлежит именно тому Магазину и т.д.),
5. проведение каких-то осмысленных бизнес-действий,
6. формирование ответа.

Кроме этой последовательности (т.н. основной успешный сценарий?) еще нужно
а) логировать действия системы
б) обрабатывать ошибки
в) сохранять информацию о запросе в каком-то хранилище

По понятным причинам хочется, что бы при возникновении ошибки на любом этапе система, во первых, порождала корректный и максимально подробный бизнес-ответ (HTTP 500 — это не ответ, это авария), во вторых, максимально подробно фиксировала "упавший" запрос в хранилище (что бы потом тех поддержка увидела проблему в своем интерфейсе).

Если рассматривать код такого приложения — он должен быть понятным, легко поддерживаемым, расшияемым и т.д. (не уверен, что полностью понимаю содержание этого "т.д.").

Моя практика показывает, что при разработке очень легко "свалиться" в чехарду обработчиков исключений, условий, записей в лог. Куча дублирующегося кода, низкое содержание смыслового кода (на одну строчку смыслового действия имеем 3-10 строк обработки ошибок). Поддерживать и расширять потом это - сущий ад.
Вопрос: как правильно организовать приложение в рамках этих требований? Что почитать?

Comments

[FoxInSox]

Кокретезируйте вопрос, сейчас все ваше полотно можно перефразировать в "Как сделать все круто".

[Denis Kostousov]

Можно и так перефразировать. Если бы я знал ответ - не стал бы спрашивать.
Мне пойдет и названия книг, где подобная проблема рассмотрена, и указания вида "погляди паттерн рога и копыта".
Думаю, можно выделить
1. как организовать обработку ошибок, что бы код не захламлять
2. как разбить обработку ошибок на независимые шаги
3. как организовать передачу данных между этими шагами

Answer 1

[sim3x]

Используй хранилище, в котором хранятся только консистентые данные
Отправляй логи в файлы
Логи агрегируй и регулярно проверяй

Answer 2

[Александр Косарев]

TDD и итеративный подход к разработке. Советую на эту тему почитать книгу Объектно-ориентированный анализ и проектирование.

Answer 3

[Андрей]

Disclaimer: это лишь мой опыт, и мое мнение.
Я бы рекомендовал почитать вообще про архитектуру Web/Enterprise приложений, и обратить внимание на четырехслойную архитектуру(слои: представлений, сервисы, бизнесс, dao). Картинку и описание этой архитектуры я не нашел, но каждый слой можно прогуглить. Сразу стоит уточнить что слой и уровень это не одно и то же.
Для изучения также можно смотреть на доклады с видео-конференций, например:

• Архитектура одноклассников
  
• Парадигмы ООП
  
• Лекции с университета (нам бы такие :))
  
• jugru
  
• jeeconf
  
• Java Day
  

Также я видел описание архитектуры Skyforge.

Если посмотреть Ваши шаги, то я бы так расставил обязанности:
1) (?) сервер приложений (если я правильно понял)
2) слой сервисов
3) dao
4) консистентность к сервисам
5) бизнесс слой
6) представления
Дополнительный свойства обеспечиваются с помощью аспектов (логи, безопасность).
Обработка ошибок, я бы назвал обработкой исключений, происходит вообще в отдельном месте, и она не относится ни к каким слоям, скорее тоже обеспечивается аспектами.
Для обеспечения "понятным, легко поддерживаемым, расшияемым и т.д. " необходимо, как ни странно, соблюдать правила Clean Code и т.п. (см. Парадигмы ООП выше).