Bagaimana Anda memodelkan domain menjadi kelas-kelas yang dirancang dengan baik?

Question

Accepted Answer

Pemodelan kelas yang baik berarti kelas-kelas yang memetakan konsep domain nyata, masing-masing dengan **satu tanggung jawab yang jelas**, terhubung melalui hubungan **is-a/has-a** yang jujur, dan bergantung pada **abstraksi** di batasan-batasan. Tidak ada formula, tetapi ada proses yang dapat diulang. ## Proses praktis ```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 ``` ## Perilaku mengikuti data ```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); } } ``` ## Heuristik yang menjaga hierarki tetap sehat | Heuristik | Alasan | |---|---| | Lebih suka komposisi; gunakan inheritance hanya untuk true is-a | Menghindari fragile base class / perangkap LSP | | Jaga hierarki tetap dangkal (2–3 level) | Pohon dalam mengaitkan segalanya | | Satu alasan untuk berubah per kelas (SRP) | Melokalisasi perubahan | | Program ke interface di seam | Testability, swappability | | Jadikan value object immutable | Menghilangkan kelas bug | ## Perangkap Jangan modelkan *seluruh* dunia di awal. Mulai kecil dengan kelas konkret; ekstrak abstraksi hanya ketika variasi nyata muncul (aturan tiga). Hierarki spekulatif tidak bertahan lama. ## Mengapa ini penting Model yang mencerminkan domain membuat kode menjelaskan dirinya sendiri — insinyur baru membaca `order.refund()` dan memahami bisnis, bukan hanya sintaksnya. Keuntungannya terakumulasi: kelas-kelas yang kohesif dan longgar bergabung melokalisasi perubahan, sehingga fitur dan perbaikan bug menyentuh beberapa file alih-alih merambat ke seluruh sistem.

Heuristik	Alasan
Lebih suka komposisi; gunakan inheritance hanya untuk true is-a	Menghindari fragile base class / perangkap LSP
Jaga hierarki tetap dangkal (2–3 level)	Pohon dalam mengaitkan segalanya
Satu alasan untuk berubah per kelas (SRP)	Melokalisasi perubahan
Program ke interface di seam	Testability, swappability
Jadikan value object immutable	Menghilangkan kelas bug