Привет!

У меня тут любопытный диалог с гопатычем вышел:

Я: Что можно почитать по проектированию классов, представляющих информацию системы (бакэнда)?

Гопатыч (сокращённо):
- David West — “Object Thinking”
- Eric Evans — “Domain-Driven Design” (главы 5–9)
- Vaughn Vernon — “Implementing Domain-Driven Design”
- Joshua Bloch — “Effective Java” (главы 2–4)
- Robert C. Martin — “Clean Code”, главы 6–11
- Martin Fowler — “Patterns of Enterprise Application Architecture”
- Michael Feathers — “Working Effectively with Legacy Code”
- Dan Bergh Johnsson, Daniel Deogun, Daniel Sawano — “Secure by Design”
- Rich Hickey — “Simple Made Easy” (доклад)
- Adam Wiggins — “The Twelve-Factor App” (factor IV и VI)
- Edward Yourdon — “Structured Design” (старенькое, но ясное)
- Yegor Bugayenko — “Elegant Objects” (т.1–2)
- Holub on Patterns (Allen Holub)
- “Domain Modeling Made Functional” — Scott Wlaschin

Я: Знаешь, что самое страшное и обидное? Я это всё кроме Secure by Design и Holub on Patterns уже прочитал. А как системно подходить к проектированию модели данных/информации своих систем - до сих пор не знаю.

Гопатыч:

Это честное и очень глубокое признание — и ты не один.
Многие, даже очень опытные инженеры (и архитекторы с 20+ годами), приходят ровно к этому рубежу:
всё про DDD, Clean Code и Fowler вроде усвоено,
а как системно проектировать саму модель информации — всё равно неясно.
Потому что нигде это не описано как отдельная дисциплина.

—

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

—

🧭 Почему тебе “не хватает системы”

Большинство источников, даже DDD, описывают что должно быть (Entities, Aggregates, Value Objects) и почему (инкапсуляция, инварианты, ubiquitous language),
но почти не говорят, как именно прийти к правильной структуре данных — то есть к набору и форме классов, которые выражают реальность твоей системы.

Причина — потому что в классическом ОО-мышлении данные вторичны относительно поведения.
А в реальных backend-системах — наоборот: данные центральны, поведение меняется вокруг них.
Нам нужен язык проектирования, где первичен информационный ландшафт, а не классы/объекты.

—

🧩 Попробуем собрать системный подход из кирпичиков
1. Начни не с классов, а с информационных потоков

Продолжение 1
Продолжение 2

PS>

Это эхо внутренней кухни работы над Эргономичной моделью данных - месяц уже ломаю голову, целевую картинку (буквально картинку - абстрактную диаграмму типа как для структуры компонентов) вижу, а описать её не выходит.