Как смоделировать домен в хорошо спроектированные классы?

Question

Accepted Answer

Хорошее моделирование класса означает классы, которые отображают реальные концепции домена, каждый с **одной четкой ответственностью**, связанные через честные отношения **is-a/has-a** и зависящие от **абстракций** на границах. Нет формулы, но есть повторяемый процесс. ## Практический процесс ```text 1. Find the NOUNS → candidate classes (Order, Customer, Payment) 2. Find the VERBS → candidate behaviors/methods (place, refund, ship) 3. Assign each behavior to the class that OWNS the data it needs (high cohesion) 4. Choose relationships: IS-A (rare, must pass LSP) vs HAS-A (default) 5. Depend on interfaces at boundaries (DIP); inject volatile dependencies 6. Keep invariants inside the object (encapsulation); prefer immutability for values ``` ## Поведение следует за данными ```java // ❌ logic separated from data (anemic) → low cohesion class Order { List items; } class OrderCalculator { double total(Order o) {...} } // ✅ behavior lives with the data it operates on class Order { private final List items; public Money total() { // owns its own rule return items.stream().map(Item::price).reduce(Money.ZERO, Money::plus); } } ``` ## Эвристики, которые сохраняют иерархии здоровыми | Эвристика | Почему | |---|---| | Предпочитайте композицию; используйте наследование только для истинной is-a | Избегает ловушек хрупкого базового класса / LSP | | Держите иерархии мелкими (2–3 уровня) | Глубокие деревья связывают всё | | Одна причина для изменения на класс (SRP) | Локализует изменение | | Программируйте к интерфейсам на границах | Тестируемость, взаимозаменяемость | | Сделайте объекты значений неизменяемыми | Устраняет целый класс ошибок | ## Подводный камень Не моделируйте весь мир заранее. Начните с малого с конкретных классов; извлекайте абстракции только когда появляется реальная вариация (правило трёх). Спекулятивные иерархии плохо стареют. ## Почему это важно Модель, которая отражает домен, делает код самообъясняющимся — новый инженер читает `order.refund()` и понимает бизнес, а не просто синтаксис. Преимущество складывается: связные, слабо связанные классы локализуют изменение, так что функции и исправления ошибок касаются нескольких файлов вместо того, чтобы волнами распространяться по системе.

Эвристика	Почему
Предпочитайте композицию; используйте наследование только для истинной is-a	Избегает ловушек хрупкого базового класса / LSP
Держите иерархии мелкими (2–3 уровня)	Глубокие деревья связывают всё
Одна причина для изменения на класс (SRP)	Локализует изменение
Программируйте к интерфейсам на границах	Тестируемость, взаимозаменяемость
Сделайте объекты значений неизменяемыми	Устраняет целый класс ошибок