Дели код на области (scope) - второй принцип. Полный список принципов здесь
Получил задачу, нужно подумать о области реализации. Иерархия областей такая: бизнес домен -> поддомен -> ... -> поддомен -> модуль(пакет) -> функция.
Чем глубже задача в иерархии декомпозиции, тем глубже область реализации в иерархии областей/слоев. Если ты разработчик, твоя зона: поддомен -> модуль(пакет) -> функция. Может быть так:
эпик содержит общее описание, покрывает несколько поддоменов, про модули тут ничего не понятно
история(сторя) в эпике описывает конкретный вариант использования, покрывает модуль поддомена. Если история покрывает больше одного модуля или поддомена, нужно подумать над декомпозицией.
техническая задача из истории - слой вниутри модуля на фронте или модуль на бэке.
Сore domain и всякие другие domain - это лирика-теория для аналитиков. Для разработчика это лишний информационных шум.
Здесь нужно быть внимательным, потому что:
границы субъективны, зависят от понимания смысла, целей, отвественности компонента,
для бэка и фронта границы областей проходят по разному в рамках одной системы:
для бэка поддомен->модуль совпадает с сервис->модуль/пакет или микросервис. Сервисы типа BFF и GraphQL - исключения, их можно считать частью глобального слоя контроллеров;
для фронта в слое контроллеров UI компоненты имеют свои границы, отличные от границ поддомен->модуль, но в остальных слоях совпадают.
Важно общаться с коллегами при обсуждении задачи, получать обратную связь и добиваться общих критериев для границ.
Допустим, я разработчик бэка. Задача: сделать фасетный и текстовый поиск товаров. Есть сторя с описанием контракта. Тогда моя зона: поддомен -> модуль(пакет) -> функция модуля. Мысли такие:
Поддомен уже понятен - обсудил в процессе декомпозиции эпика с аналитиком. Это будет Каталог. Сделаю его отдельным сервисом.
Модуль примерно понятен: мне нужно сделать фасетный поиск. Скорее всего кроме поиска Каталог-сервис будет выдавать категории, продукты по отдельности и еще что-то. Фасетный поиск - модуль.
Фасетный поиск должен возвращать значения для фасетов и результаты. Кажется, у модуля 2 функции. Может стоит сделать 2 модуля, или это будет 2 интерфейса внутри одного модуля? Решу, когда буду думать над логикой, там станет понятна связанность этих функций. Нужно будет обсудить с коллегами.
На фронте эта же задача выглядит по другому: это будет страница поиска, в ней фасетые фильтры, список товаров, страницы, сортировка. А еще где-то в шапке поле для ввода текста. Тут нет речи о Каталоге, потому что по смыслу это страница и какие-то элементы ввода. Это не страшно. Пусть структура UI компонент соответствует интуитивным ожиданиям фронт разработчиков. Важно, что бы ожидания были у всех одинаковые. Это в слое контроллеров.
В слое приложения лежит логика построения запроса по контракту. Вот здесь появляется Каталог, как поддомен, и модуль фасетного поиска. Позже тут будет модуль категорий и отдельного продукта. Слой контроллеров будет использовать их в разных UI компонентах.
Область и ограниченный контекст - разные вещи. Поэтому мы здесь его не обсуждаем.
Деление на слои и области выглядит как "решетка":
Весь код должен быть раскидан по ячейкам. Рано или поздно у вас появится общий для нескольких модулей код. Он хочет занять несколько ячеек по горизонтали. Скорее всего он выполняет общую служебную функцию внутри слоя. Здесь можно поступить по-разному: вынести в отдельный пакет, модуль с одним слоем, как договоритесь с коллегами.
Как физически организовать решетку и общие пакеты разберемся дальше.