Pastikan Anda meninjau komentar terakhir Paman Bob tentang peran desain di TDD .
Desain berbasis domain melibatkan banyak pola teknis, mendefinisikan lapisan mapan seperti lapisan Aplikasi, lapisan Infrastruktur, Lapisan Domain, lapisan Persistensi.
Udi Dahan: "Ya Tuhan, betapa aku benci layering." Dia menghabiskan waktu mendiskusikannya dalam ceramahnya CQRS - tetapi berbeda (layering dimulai pada 18m30-an)
Saya akan mengeja kalimat Anda sedikit berbeda; "DDD mengakui bahwa ada sejumlah masalah yang umum pada sebagian besar aplikasi bisnis dan bahwa solusi untuk masalah tersebut memiliki masa hidup yang berbeda" .
Misalnya masalah domain, sebagai suatu peraturan, harus fleksibel - terutama ketika Anda menyesuaikan solusi untuk bisnis tertentu. Lagi pula, domain itu menyangkut bagaimana perusahaan melakukan bisnis, yaitu, bagaimana perusahaan menghasilkan uang dan mampu memberikan perbaikan bisnis dengan cepat adalah pendapatan gratis.
Di sisi lain, Anda mungkin tidak perlu sering mengganti komponen kegigihan. Solusi database yang berfungsi rilis terakhir mungkin juga akan bekerja rilis ini.
Kekhawatiran aplikasi ada di suatu tempat di tengah; mereka cenderung stabil sehingga pengguna tidak perlu mempelajari aplikasi baru dengan setiap rilis.
Juga, bisa ada beberapa implementasi untuk menyelesaikan masalah yang diberikan. Misalnya, aplikasi mungkin hanya memerlukan snapshot dari kondisi saat ini - cukup menyimpan file ke disk sudah cukup. Dan dalam beberapa iterasi pertama Anda, itu mungkin semua kebutuhan domain juga. Tetapi pada akhirnya muncul cerita yang meminta dukungan permintaan ad-hoc, dan Anda menyadari bahwa mengonfigurasi basis data relasional akan jauh lebih mudah daripada menerapkannya dari awal. Dan kemudian ada satu fitur ini yang akan bekerja lebih baik dalam basis data grafik.
Sementara itu, CTO menginginkan versi aplikasi yang berjalan di ponselnya; CEO baru saja mendengar dari seorang lelaki bahwa penerbitan API adalah hal besar.
Juga, tim penjualan menggunakan model yang berbeda, jadi beri kami aplikasi yang sama, dengan model yang berbeda. Oh, tapi kami sering bepergian, jadi versi kami perlu berfungsi saat offline dan disinkronkan nanti ...
Dengan kata lain, Anda menerapkan pola taktis dari ddd bukan dengan menerapkan placeholder kosong dan dengan asumsi mereka akan diisi nanti, tetapi dengan mengenali ketika Anda sedang melintasi aliran "Hei, itu kode kegigihan dalam model domain saya, saya tidak boleh belum melakukan refactoring. "
