Инфраструктурный код

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

Инфраструктурный код полностью зависит от инфраструктуры проекта. Объем инфраструктурного кода напрямую зависит от того, в какой степени Вы используете функциональные возможности низлежащей инфраструктуры, перекладывая на нее свои обязанности. Если принять во внимание тот факт, что инфраструктурный код не несет прямой потребительской ценности, то можно сделать очевидный (хотя практика доказывает обратное) вывод, что в рамках имеющейся инфраструктуры необходимо использовать ее функциональные возможности настолько, насколько это возможно, и по возможности избегать создания новой инфраструктуры.

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

Пример:
Имеется система обмена сообщениями стандарта JMS и пусть каждое сообщение имеет тело сообщения (body), тип (type), имя очереди для ответа (replyTo) и имя отправителя (application name). Разработчику предлагается предложить техническую реализацию структуры сообщения.

Неправильный путь начинается с того, что разработчик придумывает свой envelop, со своим header и body секциями для хранения соответствующих полей сообщения. Продолжается написанием сложных алгоритмов анализа своего envelop'а, фактически изобретая инфраструктуру над инфраструктурой. И заканчивается все legacy кодом.

Правильным решением здесь будет воспользоваться уже готовой инфраструктурой: поля type и replyTo положить в стандартные jmsType и jmsReplyTo соответственно. С appName немного сложнее, так как для него нет стандартного jms заголовка, поэтому appName следует поместить в свойство сообщения, опять же стандартное средство инфраструктуры. С body все понятно, тут сложно промахнуться.

Аналогичный пример можно привести и для SOAP сообщений. На самом деле примеров игнорирования возможностей инфраструктуры море.

Итак, если у Вас имеется некая инфраструктура, изучите ее возможности. Большинство "велосипедов" получается из-за незнания возможностей инфраструктуры. Если так получается, что возможностей инфраструктуры недостаточно для решения конкретной задачи, то у Вас есть несколько путей решения этой проблемы:

1. Выбрать другую инфраструктуру. Это довольно радикальное решение, но все же.
2. Найти готовый framework под текущую инфраструктуру, реализующий недостающую функциональность (например NServiceBus позволяет реализовать функционал выполнения долгих бизнес процессов (известных как SAGA) в инфраструктуре MSMQ, в которой понятие SAGA отсутствует)
3. Реализовать самому.