Архитектура корпоративных программных приложений

В большинстве корпоративных приложений прослеживает-ся та или иная форма архитектурного "расслоения", но в некоторых ситуациях большее значение могут приобретать другие подходы, связанные, например, с организацией кана-лов (pipes) или фильтров (filters). Однако мы сконцетрируем внимание на архитектуре сло-ев как на наиболее плодотворной структурной модели.

Мне по душе трактовка системы в виде набора архитектурных слоев (layers)

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

В переводном издании этой книги учтены исправления, опубликованные на этой Web-странице, по со-стоянию на 1 марта 2005 года.

Я начал трудиться над рукописью в ноябре 2000 и закончил работу в июне 2002 года.

Рассматриваемые типовые решения прошли первое испытание в конце 1980-х и начале 1990-х годов, когда я работал с C++, Smalltalk и CORBA. В конце 1990-х я начал интенсивно использовать Java и обнаружил, что те же подходы оказались приемлемыми при реализации и ранних гибридных систем Java/CORBA, и более поздних проектов на основе стандарта J2EE. Недавно я стал присматриваться к платформе Mi-crosoft .NET и пришел к заключению, что решения вновь вполне применимы. Мои кол-леги по ThoughtWorks подтвердили аналогичные выводы в отношении Forte. Я не соби-раюсь утверждать, что то же справедливо для всех платформ, современных и будущих, используемых для развертывания корпоративных приложений, но до сих пор дело об-стояло именно так.

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

Я поклонник итеративного подхода к созданию программного обеспечения. А сердцем концепции итеративной разработки является положение о том, что пользова-телю следует показывать первые, пусть не полные, результаты, если в них есть хоть толика здравого смысла. Хотя между написанием программ и книг существуют, мягко говоря, заметные различия, мне хотелось бы думать, что эта — далеко не всеобъемлющая — книга все-таки окажется своего рода конспектом полезных и поучительных советов. В ней ос-вещаются следующие темы:
• "расслоение" приложения по уровням;
• структурирование логики предметной области;
• разработка пользовательского Web-интерфейса;
• связывание модулей, размещаемых в памяти (в частности, объектов), с реляцион ной базой данных;
• принципы распределения программных компонентов и данных.

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

На вашем месте я поступил бы так: детально ознакомился с материалом первой части для максимально полного понимания предмета и обратился к тем главам или типовым решениям из второй части, близкое знакомство с которыми действительно необходимо. Поэтому книгу можно воспринимать как краткий учебник (часть I), допол-ненный более увесистым руководством (часть II)