Черновик: Диаграмма Эффектов v0.0.1

Введение

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

Я потратил несколько лет на поиски готового способа декомпозиции, отличного от декомпозиции по техническим аспектам. Однако ничего не нашёл и потратил ещё два года на разработку собственного. Мой подход базируется на понятии эффекта - взаимодействии операции с состоянием системы. По этому подходу необходимо стремиться к такой декомпозиции системы, чтобы операции взаимодействовали только с состоянием своего модуля.

(todo: ООД)

(todo: почему эффектов?)

Для этого система в целом представляется графом, вершинами которого являются операции и данные, а рёбрами - обращение операций к данным. А декомпозируется система посредством разбиения этого графа на подграфы, связанные минимальным количеством рёбер

Уже после того, как у меня появились первые собственные результаты, я случайно наткнулся на очень похожий по сути подход, описанный в Improving Design Decomposition и Functional Decomposition for Software Architecture Evolution.

Однако этот подход фокусируется строго на реляционных СУБД и в качестве узлов использует отдельные колонки таблиц. На мой взгляд это делает подход не практичным - сейчас редко встречаются системы, которые взаимодействуют только с РСУБД, и любая реальная система будет иметь как минимум десятки колонок (с которыми будет очень сложно управляться).

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

Алгоритм построения

Применение

Я разработал и сейчас применяю диаграмму эффектов как основной инструмент декомпозиции системы на модули. На первом этапе я переношу сущности ER-диаграммы на диаграмму эффектов в качестве ресурсов. Затем информацию о том, какие сущности модифицируются какими операциями я использую как один из параметров процесса проектирования агрегатов - сущности которые всегда модифицируются вместе являются кандидатом на агрегат, операции, которые меняют сущности входящие в разные агрегаты являются кандидатом на перепроектирование.

Получив диаграмму эффектов с агрегатами в качестве ресурсов, я строю декомпозицию системы на модули таким образом, чтобы:

100%-ое достижение этих свойств редко возможно, поэтому я допускаю их нарушение, если это делает дизайн более "разумным" на мой субъективный взгляд.

Заключение