Доменная модель

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

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

Доменная модель сервиса МП:

Покупатель
Поставщик
Заказ
Доставка
…

История заказа оформленная в сценарий использования

Сценарий использования:

ДАНО: клиент

И поставщик

И адрес/время доставки со склада поставщика

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

Когда клиент размещает заказ,

ТОГДА его банковская карта авторизуется (выставляется счет юр. лицу)

И создается заказ в состоянии PENDING-ACCEPTANCE

И заказ привязывается к покупателю

И заказ привязывается к поставщику

Имена существительные в этом пользовательском сценарии указывают на существование классов:

Consumer (клиент),
Order (заказ),
Provider (поставщик)
Creditcard (банковская карта).
Invoice (счёт)

История получения заказа оформлена в сценарий использования:

Дано: заказ в состоянии PENDING-ACCEPTANCE

И транспортная компания, доступная для доставки заказа

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

ТОГДА состояние заказа меняется на ACCEPTED

И полю заказа promiseByTime назначается заданное время

И транспортная компания назначается для доставки заказа

Этот сценарий подразумевает существование классов:

Transport Company (транспортная компаия)
Delivery (доставка).
Address (адрес)
Catalogitem (пункт каталога)

Классы ООП:

Consumer — клиент, размещающий заказ;
Order — заказ, размещенный клиентом;
OrderLineltem — отдельная позиция в заказе;
Delivery Inf о — время и место доставки заказа;
Provider — постащик, собственник заказов для доставки клиентам;
CAtalogitem — пункт в каталоге ПОСТАВЩИКА;
Transport Company — ТК, которая доставляет клиентам заказы (отслеживает доступность машин и их местоположение);
Address — адреса клиента и поставщика;
Location — широта и долгота местонахождения автомобиля

Определение системных операций

— определение запросов, которые приложение должно обрабатывать.

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

Системные операции бывают двух видов:

команды — для создания, обновления и удаления данных C_UD
запросы — для чтения (запрашивания) данных. READ

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

Действующее лицо	История	Команда	Описание
Клиент	Создать заказ	create Order()	Создает заказ
Поставщик	Подтверждает заказ	accept Order()	поставщик принял заказ и обязуется исполнить к заданному времени
Поставщик	Заказ готов к отправке	noteOrderReadyForPickup()	заказ готов к отправке
Транспортная компания	Обновление местоположения	noteUpdatedLocation()	Обновляет текущее местоположение транспорта
Транспортная компания	Груз получен	noteDeliveryPickedUp()	Указывает на то, что груз получен ТК
Транспортная компания	Груз доставлен	noteDeliveryDelivered()	Указывает на то, что ТК доставила заказ

У команды есть спецификация, которая определяет ее параметры, возвращаемое значение и поведение в рамках классов доменной модели.

Описание поведения состоит из условий двух видов:

предварительных (ДАНО)
окончательных (ТОГДА).

Первые должны выполняться в момент вызова операции, а вторые — после.

Спецификации для системной операции createOrder().

Операция	createOrder (ID клиента, способ оплаты, адрес доставки, время доставки, ID Поставщика, позиции заказа)
Возвращает	orderld…
Предварительные условия	Клиент существует и может размещать заказы. Позиции заказа соответствуют пунктам каталога продукции. Адрес и время доставки выполнимы для поставщика
Окончательные условия	Банковская карта клиента позволила снять сумму заказа. Заказ был создан в состоянии PENDING ACCEPTANCE

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

Спецификация системной операции acceptOrder().

Операция	acceptOrder (providerId, orderId, readyByTime)
Возвращает	-
Предварительные условия	order.status равно PENDING ACCEPTANCE. Автомобиль (платформа) доступна для доставки заказа
Окончательные условия	Состояние order.status поменялось на ACCEPTED. Время order.readyByTime поменялось на readyByTime. Автомобиль назначен для доставки заказа

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

Процесс размещения заказа клиентом.

Пользователь вводит адрес и время доставки.
Система выводит доступных ПОСТАВЩИКОВ.
Пользователь выбирает ПОСТАВЩИКА.
Система выводит КАТАЛОГ ТОВАРОВ.
Пользователь выбирает ТОВАР и КАТАЛОГА и оплачивает счет.
Система создает заказ.

Сценарий использования подразумевает следующие запросы.

findAvailableProvaiders(deliveryAddress, deliveryTime) — извлекает поставщиков ИЛИ ТК, которые могут выполнить доставку по заданному адресу в заданное время.
findProvaidersCatalog(id) — извлекает информацию о ПОСТАВЩИКЕ, включая товары каталога.

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

Следующим шагом обозначение сервисов приложения.

ВАЖНО: организованы вокруг бизнес-аспектов, а не технических концепций.