Структурирование системы "Слайдомёт". Первая итерация – единый язык.

Цель итерации

Построить высокоуровневую структуру системы "Слайдомёт" и зафиксировать её картой ограниченных контекстов.

Ограниченный контекст защищает используемый язык (Ubiquitous Language) границами компонента системы (чаще всего квант).
Границы контекста не обязательно совпадают с границами предметной области (домен).

Входящие артефакты

Контекст системы

https://disk.yandex.ru/i/wDy2uQ4D1Y0Q-A

Концепты системы

https://disk.yandex.ru/i/BGQH8BWxXOSF8w

Исходящий артефакт

Карта контекстов

Шаги итерации

1. Декомпозиция
   Выделение ограниченных контекстов по языковому признаку.
2. Связывание
   Выявление связей между контекстами. Определение их направления (upstream/downstream влияние) и паттерна.
   
3. Агрегация (опционально)
   Сцепление контекстов.

Декомпозиция

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

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

Во первых выделяю контексты язык которых мне уже знаком:

• Контекст администрирования
  Авторизация/аутентификация (authn/authz), управление пользователями, сопровождение пользовательских сценариев.
  
• Контекст модерации
  Контроль открытого контента на соответствие требованиям надзоров. Удаление контента и блокировка пользователей.
  
• Контекст анализа
  "Если вы не платите за товар или услугу, то вы и есть товар".

Всё это контексты "обслуживающие" основную задачу, говорящие на своих языках.

Далее использую следующий сценарий:

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

Решения:

1. Докладчик проводит презентацию, клиент просматривает презентацию.
   Докладчик и клиент воспринимают презентацию одинаково. Основное свойство презентации и слайдов "представление". Докладчик имеет возможность навигации по слайдам. Клиент может скачивать материал. Считаю эти свойства не принципиальными для разделения языка.
   Выделяю единый контекст "Проведение презентации".
2. Докладчик проводит презентацию, разработчик разрабатывает слайды и модули.
   Слайд в понимании докладчика имеет свойства "представление" и "порядок следования". Слайд в понимании разработчика имеет состав, дизайн, версию, статус готовности. Может быть модифицирован. Существенная разница свойств приводит к выделению отдельного контекста "Разработка презентации"
3. Дизайнер разрабатывает темы и элементы визуализации. Разработчик использует эти артефакты при создании презентации. Дизайнер использует сторонние инструменты для разработки. В системе он публикует результаты работы. Для дизайнера важны следующие характеристики визуального элемента: ссылка, стоимость, количество использований демо версии и т. п.
   Для разработчика визуальный элемент описывается размером и положением на слайде. Существенно разные свойства. Выделяю контекст "Библиотека тем и элементов".
4. Остаются нераспределённые варианты использования:
   - проведение опроса,
   - создание опроса,
   - разработка (сборка) презентации.
   Не хочу плодить контексты.
   Проведение опроса отнесу к контексту "проведение презентации".
   Разработку опроса и сборку презентации отнесу контексту "разработка презентации".
5. Отдельный контекст из концептуальной модели – "Планирование встреч"

Итого получаю следующий список:

1. Проведение презентации
2. Разработка презентации
3. Библиотека тем и элементов
4. Планирование встреч
5. Администрирование
6. Модерация
7. Анализ

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

Связи контекстов

Обеспечив сцепленность, разбираемся со связанностью.

Выявляю контексты в которых создаются сущности (концепты). Они однозначно связаны с контекстами где эти сущности используются.

1. Контекст "Проведение презентации" поддерживает концепт "События" (в частности данные опросов). Используется концептом "Анализ".
2. Контекст "Разработка презентации" поддерживает концепты "Презентация", "Модуль", "Слайд". Используется контекстами "Проведение презентации", "Анализ" , "Модерация", "Администрирование".
3. Контекст "Библиотека тем и элементов" поддерживает концепты "Визуальные элементы", "Темы". Используется контекстами "Разработка презентации", "Анализ" , "Модерация", "Администрирование".
4. Контекст "Планирование встреч" поддерживает концепты "Встреча", "Участники". Используется контекстами "Проведение презентации", "Анализ" , "Администрирование".
5. Контекст "Администрирование" поддерживает концепты "Пользователь", "Роль", "Доступ". Используется всеми контекстами.
6. Контекст "Модерация" поддерживает концепты "Блокировка", "Бан". Используется концептом "Администрирование".
7. Контекст "Анализ" ни кем не используется.

Направление связей

Направление связей идут от определяющих к зависимым контекстам. То есть изменение контекста наверху (Upstream) влечёт изменение контекста внизу (Downstream).

Понятно, что наверху должны оказаться контексты:

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

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

TBD

Паттерны связей

Здесь решается вопрос, кто владеет концептом и как осуществляется трансформация концептов при переходе границы контекста.

TBD

Агрегация 

А может ну его...
Пытаемся слить всё в единый компонент.
TBD

TO BE CONTINUED