Архитектурные шаблоны проектирования
Модель предметной области
Предпосылки к созданию этого шаблона возникли после появления концепции разработки DDD (Domen Driven Design).
Шаблон "Модель предметной области" целесообразно применять в случаях, когда бизнес-логика реализуемого приложения очень сложна, имеется множество правил и условий, обосновывающих множество вариантов функционирования создаваемой системы.
Информационная система в этом случае состоит из совокупности комплексно связанных компонентов, которые должны соответствовать сущностям предметной области, автоматизированным в программном продукте. Различные сущности (или объекты) создаются во время выполнения функций программы и предоставляют "соседним" объектам в пользование методы, определенные на основе собственных классов.
При таком определении системы упрощается ее последующая модификация. Изменение реализации того или иного объекта не оказывает глобального влияния на связанные с ним объекты, при условии сохранения результата выполнения функционирования связывающих объекты методов.При использовании шаблона "Модель предметной области" компания-разработчик получает следующие преимущества:
- Система, построенная на принципах шаблона "Модель предметной области",значительно проще в понимании и дальнейшем сопровождении, особенно если речь идет о сложных отраслях бизнеса.
- Эта модель очень удобна для групповой разработки:
- Работу по реализации системы легко разделить между разработчиками, заранее оговорив принципы интеграции создаваемых модулей.
- Все создаваемые объекты являются явно или потенциально применимыми для повторного использования:
- Они независимо содержат в себе данные о состоянии и операциях объектов.
- Архитектуру системы можно разрабатывать на базе объектов или их структур, созданных ранее.
Однако при использовании сервисов использующие их объекты должны явно ссылаться на имена других объектов и однозначно "понимать" их интерфейс.Это факт необходимо учитывать при изменении системы.
Шаблон "Модель предметной области" является достаточно сложным, как для полноценной реализации, так и для понимания, поэтому есть множество "подшаблонов", которые являются его упрощенной моделью для конкретных условий эксплуатации, – к примеру, "Модуль таблицы".
В отличие от шаблона "Модель предметной области",этот шаблон содержит только по одному объекту. "Модуль таблицы" используется совместно с множеством сервисов. Сначала создается объект, а затем его дочерние "подобъекты", которым передаются аргументы.
Многоуровневая архитектура (Абстрактная машина)
С помощью шаблона "Многоуровневая архитектура" различные структурные элементы организуются по отдельным уровням, взаимосвязывающимся между собой таким образом, чтобы на более низких уровнях располагались:
- Универсальные службы общего назначения. Службы данного типа не подвергаются постоянным изменениям и наиболее универсальны с точки зрения поддержки бизнес-логики приложения.
- Службы, отвечающие за инфраструктурные взаимодействия между компонентами. Их обязанностью являются обеспечение и поддержка нефункциональных характеристик информационной системы.
На более высоких уровнях располагаются сервисы уровня логики приложения, которые подвергаются постоянным изменениям и реализуют необходимую функциональность информационных систем.
Очень важной характеристикой, которую следует соблюдать при реализации слоев, является то, что связывание уровней должно выполняться сверху вниз, а не наоборот.
Одним из слоев верхнего уровня, отвечающим за взаимодействие между программой и пользователем и несущим в себе часть реализации бизнес-логики, является слой представления.
К главным функциям этого слоя относится отображение информации и интерпретация вводимых пользователем команд с преобразованием их в соответствующие операции в соответствии с автоматизированной бизнес-логикой и содержанием источника данных.
Источник данных – подмножество функций, обеспечивающих взаимодействие со сторонними системами.
Главным отличием шаблона "Многоуровневая архитектура" от шаблона "Клиент-сервер", которые на первый взгляд очень похожи, является то, что слои располагаются совместно в одном месте, а не на разных машинах (серверах).
Наиболее известным примером данного шаблона служит модель взаимодействия открытых систем (OSI), в которой механизм обмена данными между компьютерными системами реализован на основе семиуровневой модели протоколов передачи данных.
Функциональные колодцы
Одно из современных веяний менеджмента – переход к функционально-ориентированной (построенной методом "функциональных колодцев") модели управления – ознаменовал появление соответствующего архитектурного шаблона.
Этот паттерн воплотил в себе принцип разделения функциональности информационных систем в соответствии с потребностями автоматизации отдельных объектов.
Различные функциональные модели имеют набор уникальных классов и методов, на основе которых выполняется их автоматизация.
С одной стороны, это приводит к независимости реализации отдельных моделей и повышению гибкости информационной системы в целом, но, как следствие, грозит появлением дублирующей функциональности, созданных для разных моделей.
Каждый функциональный колодец представляет собой миниатюру шаблона "Модель предметной области". Основные трудности возникают в тот момент, когда требуется выполнить интеграцию разнородных моделей в единое определение объекта.
Потоки данных
Каждая система состоит из функциональных модулей.Они получают на входе данные и преобразуют их (конвейерный подход). Каждый шаг обработки реализован в виде преобразования. Преобразования могут выполняться последовательно или параллельно, а обработка данных может быть пакетной или поэлементной.
Шаблон "Потоки данных" представляет собой алгоритмы, основанные на возможности повторного использования преобразований и возможности модификации существующей системы посредством добавления новых преобразований.
Данный паттерн прост в реализации как для систем, поддерживающих последовательный, так и параллельный способы обработки данных.
Основной недостаток данного шаблона заключается в необходимости использования общего формата данных, который должен распознаваться всеми преобразованиями. Каждое преобразование либо следует согласовывать со смежными преобразованиями относительно формата преобразовываемых данных, либо необходимо использовать стандартный формат для всех обрабатываемых данных.
Взаимодействующие подсистемы со сложными форматами ввода-вывода и большим количеством разнообразных событий достаточно сложно проектировать с использованием этого паттерна, поскольку трудно прогнозировать и обеспечить равномерный и единый по формату поток обрабатываемых данных.