Доменная модель
За отправную точку берутся требования к приложению, включая пользовательские истории и связанные с ними сценарии использования. Первый шаг на пути определения системных операций — очерчивание обобщенной доменной модели приложения.
Доменная модель создается с помощью анализа имен существительных в пользовательских историях и консультаций с экспертами в данной проблемной области.
Доменная модель сервиса МП:
- Покупатель
- Поставщик
- Заказ
- Доставка
- …
История заказа оформленная в сценарий использования
Сценарий использования:
ДАНО: клиент
И поставщик
И адрес/время доставки со склада поставщика
И суммарная цена заказа, отвечающая требованию минимального заказа
Когда клиент размещает заказ,
ТОГДА его банковская карта авторизуется (выставляется счет юр. лицу)
И создается заказ в состоянии 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) — извлекает информацию о ПОСТАВЩИКЕ, включая товары каталога.
Обобщенная доменная модель и системные операции описывают работу приложения и помогают определить его архитектуру. Поведение каждой системной операции описывается в рамках доменной модели. Каждая важная системная операция соответствует сценарию, который является важной частью описания архитектуры.
Следующим шагом обозначение сервисов приложения.
ВАЖНО: организованы вокруг бизнес-аспектов, а не технических концепций.
CoderCo
Здравствуйте, меня зовут Константин, я fullstack разработчик. На свыше 15 лет занимаюсь программированием и веб разработкой. В сферу …
ПодробнееСтоит прочитать
Экосистема решений и продуктов.
Вокруг концепции Cloud Native сложилась огромная, динамичная экосистема решений …
Выбор языка для Микросервиса
Go как нельзя лучше подходит для микросервисов, …
Контейнеры и Docker
Контейнеры - это изоляция приложения, основанная …
Микросервисы - быстрый цикл разработки и постоянный выпуск
По материалам книги Программирование Cloud Native. …
Многоступенчатая сборка
Многоступенчатая сборка — не что иное, как …
