Роберт Мартин - Чистая архитектура. Искусство разработки программного обеспечения

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

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

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

На рис. 33.1 изображена схема типичного анализа вариантов использования.

Рис. 33.1.Типичный анализ вариантов использования

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

На рис. 33.1 изображены не все варианты использования. Например, на схеме отсутствуют варианты, отвечающие за вход и выход. Это сделано специально, чтобы упростить задачу и ограничить ее размер. Если бы я включил все возможные варианты использования, эта глава могла бы превратиться в самостоятельную книгу.

Обратите внимание на варианты использования в центре на рис. 33.1, заключенные в пунктирные рамки. Это абстрактные [62] Это мой собственный стиль выделения абстрактных вариантов использования. Я мог бы использовать более стандартный UML-стереотип, такой как <>, но в данный момент я не считаю полезным следовать таким стандартам. варианты использования. Абстрактным называется такой вариант использования, который определяет общую политику для других вариантов использования. Как видите, абстрактный вариант использования Просмотр каталога наследуют варианты Просматривает каталог как зритель и Просматривает каталог как покупатель .

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

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

Рис. 33.2.Предварительная компонентная архитектура

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

Каждый компонент на рис. 33.2 потенциально представляет файл .jar или .dll и каждый будет содержать соответствующие представления, презентаторы, интеракторы и контроллеры.

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

Стал бы я действительно разбивать систему на все эти компоненты и организовывать их в файлы .jar или .dll? И да и нет. Конечно, я мог бы помудрить над компиляцией и настроить окружение так, чтобы действительно можно было создавать компоненты, развертываемые независимо. Также я мог бы оставить за собой право объединить компоненты, чтобы при необходимости получить меньшее количество единиц развертывания. Например, компоненты, изображенные на рис. 33.2, легко можно объединить в пять файлов .jar — по одному для представлений, презентаторов, интеракторов, контроллеров и утилит соответственно. В этом случае я мог развертывать компоненты, которые, скорее всего, будут меняться независимо друг от друга.

Еще один возможный вариант группировки: объединить представления и презентаторы в один файл .jar, а интеракторы, контроллеры и утилиты поместить в свои, отдельные файлы. Другой, еще более простой вариант группировки: создать два файла .jar — один с представлениями и презентаторами и другой со всем остальным.