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

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

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

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

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

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

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