Как может выглядеть разбиение одной задачи на подзадачи

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

Рассмотрим пример большой задачи «Магазин».

• A — Большую задачу можно не разделять вовсе.
• B — В отдельную подзадачу можно выделить постоянное хранилище данных. Это не значит, что в варианте A хранилища не было: оно могло существовать, но не выделялось в отдельную подзадачу и реализовывалось внутри большой задачи, например, с помощью встроенной (embedded) базы данных, подключённой к компоненту как библиотека.
• C — В большой задаче дополнительно можно выделить подзадачи чтения и записи.
• D — Также в большой задаче можно рассмотреть несколько отдельных зон ответственности, продиктованных естественными зонами предметной области.
• E — Из большой задачи можно также выделить в отдельную подзадачу механизм взаимодействия между компонентами.
• F — Логику координации между компонентами тоже можно рассматривать как отдельную подзадачу.
• G — Каждую подзадачу можно продолжить разбивать на ещё более мелкие.

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

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

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