Архитектура приложения

При проектировании приложения необходимо определить, какие его части станут клиентскими процессами, а какие процессами серверными. Понимание действующих лиц в вариантах использования, поможет определить правильную архитектуру приложения. Например, если клиенты должны получать доступ к системе через веб-браузер или мобильное устройство, то это означает, что необходимо предоставить функциональные возможности клиентского приложения через Интернет, например, используя REST-адаптер. Если «система управления запасами» получает доступ к приложению через JMS, то вы должны включить в архитектуру приложения JMS-адаптер.

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

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

Серверная часть приложения

Серверная часть приложения – это бизнес-логика, которая содержит несколько слоёв OERA, включая Business Components, Data Access и Data Source, которые обычно работают на сервере приложений.

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

Бизнес-логика для бизнес-сущности

Серверная бизнес-логика приложения состоит из набора бизнес-сущностей, которые реализуют необходимую приложению функциональность. В следующем примере бизнес-сущность CustomerBE имеет сервисы, которые реализуют функциональные возможности для клиента и его заказов. Сервис GetData используется клиентами для извлечения данных покупателя или группы покупателей и их заказов. Сервис UpdateData применяется для изменения данных о покупателе или заказе.

• Моделируйте сущности после вариантов использования.
• Сущности имеют поведение (сервисы), т.е. бизнес-логику.
• Сервисы для CustomerBE:
  • GetData
  • GetOrderData
  • UpdateData

Бизнес-данные для бизнес-сущностей

Каждая бизнес-сущность имеет ассоциированные с ней данные. Как разработчик приложения вы должны понимать, как данные для бизнес-сущности создаются и обслуживаются. Например, данными для бизнес-сущности CustomerBE могут быть имя покупателя, его адрес и заказы.

Для поддержки данных бизнес-сущностей в приложениях используются слои Data Access и Data Source, где слой Data Source обеспечивает доступ к данным в базе данных.

Данные для бизнес-сущности CustomerBE:

• Name;
• CustomerNum;
• Address;
• Order: OrderNum;
• Order: Total;
• Order: OrderLine: ItemNum;
• Order: OrderLine: Qty

Общая инфраструктура приложения

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

В терминах OERA слой Common Infrastructure предназначен для создания кода, который должен использоваться другими слоями. Хороший пример такого кода, это пользовательская аутентификация, которая может быть востребована как на уровне бизнес-сущности, так и на более низком уровне, например, на уровне базы данных. Ещё один пример, это функция отправки email (SendEmail), которая также может использоваться в различных частях приложения.