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

Подождите немного. Документ загружается.

134 Часть II. Типовые решения

Простые случаи не требуют особых объяснений. Разумеется, как и при написании

иных программ, структурировать код по модулям следует осмысленно. Это не должно

вызывать затруднений, если только транзакция не оказывается слишком сложной. Одно

из основных преимуществ сценария транзакции заключается в том, что вам не приходится

беспокоиться о наличии и вариантах функционирования других параллельных транзак-

ций. Ваша задача — получить входную информацию, опросить базу данных, сделать вы-

воды и сохранить результаты.

Где расположить сценарий транзакции, зависит от организации слоев системы. Этим

местом может быть страница сервера, сценарий CGI или объект распределенного сеанса.

Я предпочитаю обособлять сценарии транзакции настолько строго, насколько это воз-

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

лучше — в классах, отличных от тех, которые относятся к слоям представления и источ-

ника данных. Помимо того, следует избегать вызовов, направленных из сценариев тран-

закции к коду логики представления; это облегчит тестирование сценариев транзакции и

их возможную модификацию.

Существует два способа разнесения кода сценариев транзакции по классам. Наиболее

общий, прямолинейный и удобный во многих ситуациях — использование одного класса

для реализации нескольких сценариев транзакции. Второй, следующий схеме типового

решения команда (Command) [20], связан с разработкой собственного класса для каждого

сценария транзакции (рис. 9.1): определяется тип, базовый по отношению ко всем коман-

дам, в котором предусматривается некий метод выполнения, удовлетворяющий логике

сценария транзакции. Преимущество такого подхода — возможность манипулировать эк-

земплярами сценариев как объектами в период выполнения, хотя в системах, где бизнес-

логика организована с помощью сценариев транзакции, подобная потребность возникает

сравнительно редко. Разумеется, во многих языках модель классов можно полностью иг-

норировать, полагаясь, скажем, только на глобальные функции. Однако вполне очевид-

но, что аппарат создания объектов помогает преодолевать проблемы потоков вычисле-

ний и облегчает изоляцию данных.

Рис. 9.1. Пример иерархии наследования классов, реализующих

сценарии транзакции

Глава 9. Представление бизнес-логики 135

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

иметь дело с одним сценарием для каждой транзакции уровня системы баз данных. Пусть

такой исход нельзя гарантировать на все сто процентов, но в первом приближении это

верно.

Назначение

Главным достоинством типового решения сценарий транзакции является простота.

Именно такой вид организации логики, эффективный с точки зрения восприятия и про-

изводительности, весьма характерен и естествен для небольших приложений.

По мере усложнения бизнес-логики становится все труднее содержать ее в хорошо

структурированном виде. Одна из достойных внимания проблем связана с повторением

фрагментов кода. Поскольку каждый сценарий транзакции призван обслуживать одну

транзакцию, все общие порции кода неизбежно приходится воспроизводить вновь и

вновь.

Проблема может быть частично решена за счет тщательного анализа кода, но наличие

более сложной бизнес-логики требует применять модель предметной области (Domain

Model, 140). Последняя предлагает гораздо больше возможностей структурирования ко-

да, повышения степени его удобочитаемости и уменьшения повторяемости.

Определить количественные критерии выбора конкретного типового решения до-

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

другие. Проект, основанный на сценарии транзакции, с помощью техники рефакторинга

(refactoring) вполне возможно преобразовать в реализацию модели предметной области, но

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

вите все точки над /, тем лучше. Однако каким бы ярым приверженцем объектных техно-

логий вы ни становились, не отбрасывайте сценарий транзакции: существует множество

простых проблем, и их решения также должны быть простыми.

Задача определения зачтенного дохода

Рассматривая различные типовые решения по организации бизнес-логики, удобно

воспользоваться одним и тем же примером. Чтобы не повторять формулировку пробле-

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

Определение зачтенного дохода (revenue recognition) является довольно типичной за-

дачей во многих отраслях бизнеса. Речь, по существу, идет о том, когда и как именно сле-

дует учитывать доходы от продажи товаров и услуг. Если я продаю вам чашку кофе, все

просто: вы получаете продукт, я беру деньги и мгновенно фиксирую их в кассовом аппа-

рате. Однако во многих случаях дело обстоит значительно сложнее. Предположим, вы

платите мне гонорар за услуги, оказываемые на протяжении года. Каким бы образом пла-

та ни вносилась (даже ежедневно), я, вероятно, не смогу ее учесть в своих бухгалтерских

книгах непосредственно, поскольку договор, как мы условились, подписан на год. Мож-

но, например, вести зачет, отображая двенадцатую часть суммы в каждом месяце.

Правила определения зачтенного дохода многочисленны, разнообразны и нестабиль-

ны. Одни устанавливаются законом, другие регламентируются профессиональными

стандартами, третьи вытекают из корпоративной политики. Поэтому проблема в общей

постановке может быть довольно сложной.

136 Часть II. Типовые решения

Но я не собираюсь вдаваться в детали. Представим компанию, которая продает три

типа программных продуктов — текстовые процессоры, СУБД и электронные таблицы.

Допустим, что в соответствии с правилами при продаже текстового процессора следует

учитывать сразу всю сумму; если речь идет об электронных таблицах, третья часть суммы

может быть отображена в бухгалтерской отчетности в день продажи, вторая треть—60-ю

днями позже, а оставшаяся треть — через 90 дней; если продана СУБД, схема зачета та-

кова: треть суммы сегодня, треть по истечении 30дней, а треть— через 60дней. (Иных

оснований, кроме моего больного воображения, у этого регламента нет, хотя реальные

правила подчас ничуть не лучше.) Упрощенная схема определения зачтенного дохода

представлена на рис. 9.2.

Рис. 9.2. Упрощенная схема определения зачтенного дохода: общий зачтенный доход по контракту

складывается из нескольких значений

Пример: определение зачтенного дохода (Java)

В примере используются два сценария транзакции: один для вычисления зачтенного

дохода по контракту, а второй — для определения части дохода по контракту, зачтенной к

заданной дате. Схема базы данных содержит описания трех таблиц, предназначенных для

хранения сведений о продуктах (products), контрактах (contracts) и зачтенных дохо-

дах (revenueRecognitions).

CREATE TABLE products (ID int primary key, name varchar,

^Otype varchar)

CREATE TABLE contracts (ID int primary key, product int,

"^revenue decimal, dateSigned date)

CREATE TABLE revenueRecognitions (contract int, amount decimal,

4>recognizedOn date, PRIMARY KEY (contract, recognizedOn))

Первый сценарий вычисляет доход, зачтенный на определенную дату, путем поиска

соответствующих записей в таблице revenueRecognitions и суммирования значений

ПОЛЯ amount.

Во многих случаях сценарии транзакции содержат SQL-код, оперирующий информа-

цией в базе данных напрямую. Здесь же в качестве оболочки SQL-запросов используется

простой шлюз таблицы данных (Table Data Gateway, 167). Поскольку пример слишком

Глава 9. Представление бизнес-логики 137

прост, вместо отдельных шлюзов для каждой таблицы применяется один общий шлюз.

Ниже показано, как может выглядеть метод поиска данных в шлюзе.

class Gateway...

public ResultSet findRecognitionsFor(long contractID,

4>MfDate asof) throws SQLException {

PreparedStatement stmt = db.prepareStatement(

4>findRecognitionsStatement) ;

stmt.setLong(1,contractID); stmt.setDate(2,

asof.toSqlDate() ) ; ResultSet result =

stmt.executeQuery(); return result; }

private static final String findRecognitionsStatement =

"SELECT amount " + "FROM revenueRecognitions " + "WHERE

contract = ?AND recognizedOn <= ?"; private Connection

db;

Сценарий суммирования значений amount, возвращенных методом объекта шлюза,

представлен ниже.

class RecognitionService...

public Money recognizedRevenue(long contractNumber,

"bMfDate asOf) {

Money result = Money.dollars(0);

try {

ResultSet rs = db.findRecognitionsFor(contractNumber,

asOf);

while (rs.nextO) {

result = result.add(Money.dollars(rs.getBigDecimal ( "amount")));

}

return result;

} catch (SQLException e) {throw

new ApplicationException (e);

Если процесс вычисления настолько прост, можно заменить сценарий, обрабаты-

вающий данные в памяти, вызовом SQL-запроса с агрегирующей функцией, обеспечи-

вающей суммирование значений amount.

Для вычисления зачтенного дохода по существующему контракту я применяю схожий

вариант расщепления кода. Сценарий сосредоточивает в себе необходимую бизнес-

логику.

class RecognitionService...

public void calculateRevenueRecognitions(

long contractNumber) { try {

ResultSet contracts = db.findContract(contractNumber);

contracts.next() ;

138 Часть II. Типовые решения

Money totalRevenue =

Money.dollars(contracts.getBigDecimal("revenue"));

MfDate recognitionDate = new MfDate(contracts.getDate (

"dateSigned"));

String type = contracts.getString("type");

if (type.equals("S")) {

Money[] allocation = totalRevenue.allocate(3);

db.insertRecognition

(contractNumber, allocation[0],

recognitionDate) ;

db.insertRecognition

(contractNumber, allocation[1],

recognitionDate.addDays(60) ) ;

db.insertRecognition

(contractNumber, allocation[2],

recognitionDate.addDays(90)) ;

} else if (type.equals("W") ) {

db.insertRecognition(contractNumber, totalRevenue,

recognitionDate);

} else if (type.equals("D")) (

Money[] allocation = totalRevenue.allocate (3);

db.insertRecognition

(contractNumber, allocation[0],

recognitionDate);

db.insertRecognition

(contractNumber, allocation[1],

recognitionDate.addDays(30));

db.insertRecognition

(contractNumber, allocation[2],

recognitionDate.addDays (60));

} catch (SQLException e) (throw

new ApplicationException(e);

}

)

Для создания объектов, представляющих денежные величины, используется типовое

решение деньги (Money, 502), ведь при делении денежной суммы так легко потерять ко-

пейку из-за ошибок округления!

Поддержка SQL обеспечивается с помощью шлюза таблицы данных. Ниже приведен

метод поиска контракта.

class Gateway.. .

public ResultSet findContract (long contractID)

throws SQLException {

PreparedStatement stmt = db.prepareStatement(

bfindContractStatement);

stmt.setLong(1, contractID); ResultSet

result = stmt.executeQuery(); return

result; )

private static final String findContractStatement =

"SELECT *" +

Глава 9. Представление бизнес-логики 139

"FROM contracts с, products p " +

"WHERE ID = ?AND c.product = p.ID";

Далее приведена функция-оболочка SQL-команды вставки.

class Gateway...

public void insertRecognition (long contractID,

^Money amount, MfDate asof) throws SQLException {

PreparedStatement stmt = db.prepareStatement(

'binsertRecognitionStatement);

stmt.setLong(1, contractID);

stmt.setBigDecimal(2, amount.amount());

stmt.setDate(3, asof.toSqlDate());

stmt.executeUpdate(); }

private static final String insertRecognitionStatement =

"INSERT INTO revenueRecognitions VALUES (?, ?, ?)";

В системе Java служба определения зачтенного дохода ("recognition service") может

быть обычным классом или компонентом сеанса (session bean).

Сопоставив все это с соответствующим примером, иллюстрирующим модель предмет-

ной области, вы убедитесь в том, что подход, основанный на сценарии транзакции, на-

много проще. Гораздо труднее представить, что произойдет при усложнении бизнес-

логики. Правила бухгалтерского учета доходов весьма запутанны и часто зависят не толь-

ко от типа продукта, но и от даты подписания контракта. По мере расширения набора

правил и их усложнения код сценария транзакции становится все труднее содержать в по-

рядке, и потому адепты объектного подхода (такие, как я) в подобных обстоятельствах

предпочитают обращаться к модели предметной области.

140 Часть II. Типовые решения

Модель предметной области (Domain Model)

Объектная модель домена, охватывающая поведение (функции)

и свойства (данные)

В своих наихудших проявлениях бизнес-логика бывает чрезвычайно сложной, с мно-

жеством правил и условий, оговаривающих различные варианты использования и осо-

бенности поведения системы. Для облегчения именно таких трудностей и предназначены

объекты. Типовое решение модель предметной области предусматривает создание сети

взаимосвязанных объектов, каждый из которых представляет некую осмысленную сущ-

ность — либо такую крупную, как промышленная корпорация, либо настолько мелкую,

как строка формы заказа.

Принцип действия

Реализация модели предметной области означает пополнение приложения целым сло-

ем объектов, описывающих различные стороны определенной области бизнеса. Одни

объекты призваны имитировать элементы данных, которыми оперируют в этой области,

а другие должны формализовать те или иные бизнес-правила. Функции тесно сочетаются

сданными, которыми они манипулируют.

Объектно-ориентированная модель предметной области часто напоминает схему со-

ответствующей базы данных, хотя между ними все еще остается множество различий.

В модели предметной области смешиваются данные и функции, допускаются многознач-

ные атрибуты, создаются сложные сети ассоциаций и используются связи наследования.

В сфере корпоративных программных приложений можно выделить две разновидно-

сти моделей предметной области. "Простая" во многом походит на схему базы данных

Глава 9. Представление бизнес-логики 141

и содержит, как правило, по одному объекту домена в расчете на каждую таблицу.

"Сложная" модель может отличаться от структуры базы данных и содержать иерархии

наследования, стратегии и иные [20] типовые решения, а также сложные сети мелких

взаимосвязанных объектов. Сложная модель более адекватно представляет запутанную

бизнес-логику, но труднее поддается отображению в реляционную схему базы данных.

В простых моделях подчас достаточно применять варианты тривиального типового ре-

шения активная запись (Active Record, 182), в то время как в сложных без замысловатых

преобразователей данных (Data Mapper, 187) порой просто не обойтись.

Бизнес-логика обычно подвержена частым изменениям, поэтому весьма важна воз-

можность простой модификации и тестирования этого слоя кода. Отсюда следует на-

стоятельная необходимость снижать степень зависимости модели предметной области от

других слоев системы. Более того, как вы сможете убедиться, именно это требование яв-

ляется основополагающим аспектом многих типовых решений, имеющих отношение

к "расслоению" системы.

С моделью предметной области связано большое количество различных контекстов.

Простейший вариант— однопользовательское приложение, где единый граф объектов

считывается из дискового файла и располагается в оперативной памяти. Такой стиль ра-

боты присущ настольным программам, но менее характерен для многоуровневых прило-

жений, поскольку в них намного больше объектов. Размещение каждого объекта в памя-

ти сопряжено с чрезмерными затратами ресурсов памяти и времени. Прелесть объектно-

ориентированных систем баз данных заключается в том, что они создают впечатление,

будто объекты пребывают в памяти постоянно.

Без такой системы заботиться о создании объектов вам придется самому. Обычно

в ходе выполнения сеанса в память загружается полный граф объектов, хотя речь вовсе

не идет обо всех объектах и, может быть, классах. Если, например, ведется поиск мно-

жества контрактов, достаточно считать информацию только о таких продуктах, кото-

рые упоминаются в этих контрактах. Если же в вычислениях участвуют объекты кон-

трактов и зачтенных доходов, объекты продуктов, возможно, создавать вовсе не нужно.

Точный перечень данных, загружаемых в память, определяется параметрами объектно-

реляционного отображения.

Если в продолжение процесса обработки нескольких вызовов необходим один и тот

же граф объектов, состояние сервера следует каким-то образом сохранять (подобным во-

просам посвящена глава 6, "Сеансы и состояния").

Одна из типичных проблем бизнес-логики связана с чрезмерным увеличением объек-

тов. Занимаясь конструированием интерфейсного экрана, позволяющего манипулиро-

вать заказами, вы наверняка заметите, что только некоторые функции отличаются сугубо

специфическим характером и узким назначением. Возлагая на единственный класс зака-

за всю полноту ответственности, вы рискуете раздуть его до непомерной величины. Что-

бы избежать подобного, можно выделить общие характеристики "заказов" и сосредото-

чить их в одноименном классе, а все остальные функции вынести во вспомогательные

классы сценариев транзакции (Transaction Script, 133) или даже слоя представления.

При этом, однако, возникает опасность повторения фрагментов кода. Функции, не

относящиеся к категории общих, отыскать довольно трудно, и многие предпочитают

этим просто не заниматься, соглашаясь с дублированием кода. Повторение часто приво-

дит к усложнению и несогласованности, хотя, по моему мнению, эффекты излишнего

увеличения размеров классов наблюдаются значительно реже, чем можно было ожидать.

142 Часть II. Типовые решения

Если такое действительно происходит, результаты вполне очевидны и легко поправимы.

Поэтому советую размещать весь родственный код в пределах одного класса и занимать-

ся его разделением по нескольким классам только тогда, когда это в самом деле целесо-

образно.

ОСОБЕННОСТИ JAVA-РЕАЛИЗАЦИИ

Замечено, что, когда начинается обсуждение разработки модели предметной

области средствами J2EE, происходят резкие колебания орбиты Земли. Многие

учебники и вводные курсы, посвященные тематике J2EE, для реализации моде-

лей предметной области рекомендуют использовать компоненты сущностей

(entity beans), хотя подобный подход, как известно, грешит некоторыми серьез-

ными проблемами (это характерно по меньшей мере для текущей версии (2.0)

спецификации Java).

Компоненты сущностей особенно полезны при использовании технологий

управления хранением данных на уровне контейнера (Container Managed Per-

sistence — CMP). Я сказал бы больше: вне контекста СМР применение компо-

нентов сущностей практически лишено смысла. Однако СМР представляет со-

бой слишком ограниченную форму объектно-реляционного отображения и не

в состоянии обеспечить поддержку многих типовых решений, дополняющих

сложную модель предметной области.

Компоненты сущностей не должны быть реентерабельными, т.е. не должны

поддерживать возможность повторного вхождения. Иными словами, если ком-

понент сущностей вызывает другой объект, этот (или следующий в цепочке

ссылок) объект не в состоянии адресовать исходный компонент. В сложных мо-

делях предметной области свойство реентерабельности используется довольно

часто, поэтому отсутствие такового у компонентов сущностей представляет

серьезное препятствие. Что еще хуже, образцы реентерабельного поведения

бывает трудно распознать. Поэтому некоторые просто ограничиваются тем, что

не позволяют одним компонентам сущностей вызывать другие. Такой подход

исключает проблему реентерабельности, но во многом снижает достоинства

модели предметной области как таковой.

В модели предметной области должны использоваться объекты и интерфейсы

высокого уровня детализации. Компоненты сущностей могут вызываться в уда-

ленном режиме (в соответствии с более ранними спецификациями Java такое

условие было обязательным). Наличие удаленных объектов, снабженных де-

тальными интерфейсами, значительно снижает производительность системы.

Для преодоления проблемы достаточно использовать компоненты сущностей

только в локальном режиме.

Для функционирования компонентам сущностей необходимы контейнер и

подключение к базе данных. Выполнение этих условий требует дополнитель-

ного времени. Помимо того, код компонентов сущностей с большим трудом

поддается отладке.

Приемлемой альтернативой являются обычные объекты Java, хотя это часто

служит источником недоразумений — многие считают, будто такие объекты

Java не способны работать в контексте EJB-контейнера. Полагаю, о традицион-

ных объектах Java забывают только потому, что для них не придумали какого-то

броского названия. Готовясь к докладу на конференции в 2000 году, Ребек-

ка Парсонз (Rebecca Parsons), Джошуа Маккензи (Josh Mackenzie) и я таковое

Глава 9. Представление бизнес-логики 143

изобрели: POJO — plain old Java objects. Модель предметной области на основе

объектов POJO проста в реализации, независима от EJB и допускает возмож-

ность функционирования и тестирования вне EJB-контейнера (именно поэто-

му поставщики EJB не заинтересованы в успехе POJO).

Мое мнение таково: использование компонентов сущностей как инстру-

ментов реализации модели предметной области оправданно, если бизнес-логика

в достаточной мере скромна. В этой ситуации можно построить модель, наде-

ленную простыми связями с базой данных, и предусмотреть, скажем, по одному

классу компонента сущностей на каждую таблицу. Если же бизнес-логика ос-

нована на механизме наследования, стратегиях и иных замысловатых типовых

решениях, лучше прибегнуть к объектам POJO в сочетании с преобразователями

данных, воспользовавшись коммерческими инструментами или доморощенным

слоем кода.

Занимаясь сложной моделью предметной области, хочется оставаться в воз-

можно более полной независимости от среды реализации, но технологии EJB

требуют слишком серьезного внимания.

Назначение

Если вопросы как, касающиеся модели предметной области, трудны потому, что пред-

мет чересчур велик, вопрос когда сложен ввиду неопределенности ситуации. Все зависит

от степени сложности поведения системы. Если вам приходится иметь дело с изощрен-

ными и часто меняющимися бизнес-правилами, включающими проверки, вычисления

и ветвления, вполне вероятно, что для их описания вы предпочтете объектную модель.

Если, напротив, речь идет о паре сравнений значения с нулем и нескольких операциях

сложения, проще прибегнуть к сценарию транзакции (Transaction Script, 133).

Существует еще один фактор, который нельзя обойти вниманием: насколько ком-

фортно чувствует себя команда разработчиков, манипулируя объектами домена. Изуче-

ние способов проектирования и применения модели предметной области — урок крайне

сложный, пробудивший к жизни целый информационный пласт о "смене парадигмы".

Чтобы привыкнуть к модели, нужны практика и советы профессионала, но зато среди

тех, кто дошел до цели, мне почти не встречались такие, кто хотел бы вновь вернуться

к сценарию транзакции, — разве только в самых простых случаях.

При необходимости взаимодействия с базой данных в контексте модели предметной

области прежде всего я обратился бы к преобразователю данных. Это типовое решение

поможет сохранить независимость бизнес-модели от схемы базы данных и обеспечить

наилучшие возможности изменения их в будущем.

Встречаются ситуации, когда модель предметной области целесообразно снабдить бо-

лее отчетливым интерфейсом API, и для этого можно порекомендовать типовое решение

слой служб (Service Layer, 156).

Дополнительные источники информации

Почти каждая книга об объектно-ориентированном проектировании так или иначе

затрагивает модели предметной области, так как именно они зачастую находятся в центре

внимания разработчиков прикладных систем.

Если вам нужно введение в объектные технологии, лучшим на сегодня, по моему

мнению, является пособие [26]. За примерами моделей предметной области обращайтесь