Комментарии 2
1. Вы вводите термин "модуль".
2. Начинаете разбирать определение 2020 года.
3. Вы говорите, что модули выстраиваются в определенную систему.
4. Буквально: "Далее, чтобы продолжить применять DIP, нам необходимо выделить в коде приложения модули, а затем расположить модули относительно вертикальной оси (далее эту ось мы будем называть ось уровня абстракции), выстроив иерархию между ними"
Как это? Что значит продолжить применять DIP? Где вы его до этого применяли, если вы только собираетесь выделять модули?
-----
Что бы выделить модули в коде и строить зависимости:
1. Необходимо классифицировать код. Дан пример классификации.
2. "Модули объединяют в более крупные структуры — слои"
Минуточку, все это началось с того, что мы хотели выделить модули. Как это модули объединяют в слои, если мы еще не выделили модули?
И на этом с модулями все? Наверное, можно попытаться понять, что вы имели в виду, но получилась какая-то чехарда. Строгого выстроенного введения, по моему, не получилось.
----
"Особенностью большинства увиденных мной подходов к написанию кода является то, что классификация по назначению не всегда соответствует (почти никогда) реальной декомпозиции кода на структурные элементы." - это на какие элементы? Вы выше ввели термин модуль и сразу про него забыли. Это модули имеются в виду?
"Тем не менее, в любом коде независимо от языка программирования, парадигмы и «чистоты» (даже если это процедура на несколько сотен строк) можно найти код соответствующий этим категориям — прежде чем что-то сделать с данными необходимо их каким-то образом получить, ну а то что ваш код делает с данными, как правило, кому-то нужно. " - как это связано с предыдущим предложением в этом же абзаце? Каким этим категориям, если только что речь шла о структурных элементах?
"Итак, код нашего гипотетического приложения мы сгруппировали в модули..." - как это??? Мы его только классифицировали. В лучшем случае мы худо бедно сгруппировали код в слои. До модулей мы же не дошли. Или дошли уже?
Дальше пока читать не буду, потому что если там так же, то ни в чем разобраться не смогу.
DIP (как и другие принципы SOLID) — это принципы, помогающие улучшать и корректировать архитектуру уже после того, как структура задачи и основные сущности уже ясны:
❌ Не начинайте проект с DIP.
✅ Начинайте проект с явлений, событий, предметной области и реальной структуры данных.
Сначала поймите, что вообще реально происходит (бизнес-явления, события). Опишите их максимально простыми понятиями (да хоть бы и JSON-структурой, после завершения обследования предметной области заменить на типизацию).
И только после того, как станет понятно, что на самом деле есть «зависимость», какую реализацию в будущем вам, вероятно, нужно будет заменить, будет ли меняться что-то часто — только тогда стоит вводить защитные абстракции. Когда появятся ясные границы в понимании тогда и будете их делать в коде.
DIP, SLAP, Coupling — База