Hai, Habr.Hari ini saya pergi ke saluran
#school di GoCommunity di Slack berbahasa
Rusia dan menemukan
satu dialog yang menarik di sana . Dialog ini membawa saya pada beberapa pemikiran tentang bagaimana rekan kerja saya menafsirkan konsep
"model domain" .
Ternyata, ada cukup banyak interpretasi yang salah atau tidak cukup akurat, dan kadang-kadang sama sekali tidak akurat dari istilah ini, yang pada dasarnya mendistorsi itu. Sekitar dialog ini, ide artikel ini lahir. Detail di bawah potongan.
Pertanyaan tentang arsitektur.
Jadi, pengembang mengajukan pertanyaan berikut di komunitas:
Beri tahu saya cara melakukan arsitektur dengan benar, katakanlah saya membuat tablet di basis data, meminta reformasi untuk menghasilkan model bagi saya, dapatkah saya menggunakan model ini sebagai model domain dalam aplikasi saya, atau lebih baik membuat model domain sendiri dan membuat adaptor yang akan memberi saya model domain persis seperti saya menciptakannya dari model reformasi? "
Untuk siapa programmer lain memberikan jawaban berikut:
Yang paling sederhana adalah arsitektur dengan model anemia. ini adalah ketika model DB = model domain = model respons API. model domain kaya adalah binatang langka dan biasanya berubah menjadi anemia. Yang dimaksud dengan anemia adalah struktur DTO. set atribut (bidang) yang biasa tanpa metode. Logika merosot menjadi seperangkat fungsi yang beroperasi pada dto tersebut. Fowler kadang-kadang menganggap arsitektur seperti itu sebagai antipattern. Tapi kemudian solusi microservice yang baik, dll.
Setelah membaca ini, saya tiba-tiba menyadari mengapa ada begitu banyak kontroversi seputar organisasi lapisan logika bisnis, dan mengapa banyak orang gagal mempraktikkan pendekatan seperti
Arsitektur Bersih , dll. Apa yang dimaksud dengan
"arsitektur dengan model anemia" ?
Jika Anda mencoba menemukan konsep seperti itu di jaringan, kemungkinan besar Anda tidak akan menemukannya, karena tidak ada arsitektur seperti itu. Ada konsep
"AnemicDomainModel" , dan jika kita beralih ke Fowler yang sama, ternyata ini hanya
pendekatan prosedural untuk membuat arsitektur aplikasi (halo Fortran, ALGOL, COBOL, BASIC, Pascal dan C). Ini, pada dasarnya, adalah apa yang oleh penulis jawaban disebut
"arsitektur dengan model anemia" .
Model domain.
Selanjutnya, pertanyaan berikutnya muncul: apakah
"model anemia" pada dasarnya adalah model? Saya pikir tidak, dan itu sebabnya.
Yang benar adalah bahwa model domain bukan model data, tidak seperti
"model DB" atau
"model respons API" . Model domain
memiliki definisi yang sangat spesifik . Selain itu, salah untuk mengganggu model database, yang pada dasarnya adalah
model data .
Ketika datang ke model domain, ini justru model konseptual. Dan ini adalah totalitas konsep area subjek dan hubungan di antara mereka (mis. Totalitas perilaku dan data). Secara umum, fitur utama yang membedakan satu model area subjek dari yang lain adalah seperangkat aturan bisnis.
Ya, model konseptual dapat bekerja dengan data yang disajikan dalam berbagai bentuk (data dari database atau tanggapan API), tetapi esensi dari ini tidak akan berubah,
perilaku sangat penting . Kami meneruskan input ke model untuk mendapatkan output spesifik. Hasil ini dicapai dengan menerapkan logika bisnis dalam model (dengan kata lain, menerapkan aturan bisnis). Saya menemukan di sini analogi dengan model matematika dan pemodelan proses teknologi (halo siswa tahun).
Apa yang penuh dengan penggantian konsep?
Saat Anda menyebut struktur data sebagai
"model domain" , Anda bebas atau tidak mengganti konsep. Ini mengarah pada fakta bahwa logika bisnis sering tersebar di seluruh aplikasi. Bahkan, model area subjek dalam kasus ini adalah himpunan fungsi yang sangat berlumuran yang beroperasi dengan struktur data.
Dalam kasus pengembangan aplikasi menengah dan besar, kesalahpahaman atau pencampuran konsep-konsep ini, sebagai suatu peraturan, mengarah ke sejumlah masalah dan pertanyaan yang sudah ada di awal pengembangan sistem, belum lagi dukungan jangka panjang. Di antara mereka, misalnya, ada pertanyaan umum seperti:
- "- Di mana memvalidasi data?"
- "- Bagaimana cara menghindari ketergantungan siklik?"
- "- Apakah logika bisnis" ini "secara umum?"
- "- Dan di mana kita menyimpan logika bisnis?"
- dll.
Selain itu, jika Anda memiliki CRUD sederhana, mis. pada dasarnya antarmuka ke database, kemungkinan besar tidak akan ada masalah. Jika Anda menulis pustaka tingkat infrastruktur (misalnya, untuk bekerja dengan jaringan atau dengan database yang sama), seharusnya juga tidak ada masalah. Itu karena ada RFC dan semua "aturan bisnis" sudah lama jelas, dan logikanya sudah lama jelas. Anda dapat menulis program prosedural sederhana, dan semuanya akan baik-baik saja.
Jika kita kembali ke kenyataan bahwa dialog tentang model domain muncul di komunitas Go, saya akan mengatakannya. Karena fakta bahwa Go adalah bahasa multi-paradigma dan mendukung sejumlah konsep OOP paling sukses (Komposisi, Antarmuka), jangan abaikan saat memodelkan domain dan menulis kode secara eksklusif dalam gaya prosedural, seolah-olah Anda bekerja dengan BASIC atau C.
Mengartikan konsep "model domain" dengan benar, menjadi sangat jelas mengapa sering kali memisahkan logika bisnis menjadi lapisan yang terpisah. Ini juga menjadi jelas bagaimana Anda dapat memilih lapisan yang sama ini dan menerapkan Arsitektur Bersih atau variasi lainnya. Dengan mengisolasi lapisan yang terpisah, kami pada dasarnya membuat perpustakaan yang mengimplementasikan model konseptual dalam bentuk kode program. Akibatnya, logika bisnis menjadi terbungkus dalam kerangka perpustakaan ini, dan tidak menyebar ke seluruh aplikasi (seperti dengan pendekatan prosedural murni).
Tentu saja, memahami konsep-konsep ini tidak akan menyelamatkan Anda dari kesalahan desain, tidak akan membuat Anda seorang pengembang atau arsitek sistem yang ideal, dan tidak akan mengajarkan Anda untuk melakukan segalanya dengan benar pada kali pertama. Di sini, tidak hanya teori yang penting, tetapi juga praktik. Namun demikian, segera setelah Anda benar memahami konsep dan menafsirkan definisi, banyak hal akan menjadi jauh lebih jelas dan sederhana bagi Anda.
Untuk meringkas.
- Tidak benar menyebut "data" model domain.
- Model domain adalah model konseptual yang mencakup perilaku dan data. Itu dapat dienkapsulasi dalam lapisan terpisah, atau dapat disebarkan ke seluruh aplikasi.
- "Arsitektur dengan model anemia" tidak lebih dari pendekatan prosedural untuk menciptakan arsitektur aplikasi di mana model domain tersebar di seluruh aplikasi
Perhatikan definisi, pelajari lebih dalam daripada hanya membaca secara diagonal. Sangat sering kita malas dan mengambil informasi berkeping-keping, setelah itu pasti terjadi distorsi. Jangan lupa untuk kembali dan mengingat hal-hal yang tampak jelas bagi Anda untuk waktu yang lama, dan selalu merujuk pada sumber dan menyebut sekop sekop.
Baik untuk semua! Terima kasih atas perhatian anda
PS. Saya akan senang mendengarkan kritik konstruktif, serta visi Anda tentang apa "model domain" itu. Referensi ke sumber dipersilahkan.
UPD: Artikel ini bukan upaya untuk secara bebas menafsirkan konsep "model domain" dan memasukkan ke dalam konsep ini satu makna yang saya tahu. Saya ingin menyampaikan ini: Makna dalam konsep ini telah lama diinvestasikan, dan dijelaskan secara rinci dalam buku dan artikel tentang ComputerScience. Artikel ini adalah upaya untuk menyampaikan kepada rekan-rekannya tentang pentingnya persepsi yang benar dari konsep-konsep ini tanpa menyimpangkan maknanya (Ini penting karena dalam praktiknya ini akan memungkinkan Anda untuk menulis kode yang lebih bermakna).
UPD2: Saya bukan arsitek ahli teori perusahaan. Saya adalah pengembang yang sama dengan Anda. Saya menulis kode setiap hari dan membicarakan hal-hal ini untuk membuat kode saya lebih baik, dan pelanggan lebih bahagia. Jika, menurut Anda, saya telah menyimpangkan makna aslinya, membagikan tautan ke sumber dan menunjukkan di mana saya meletakkannya dengan salah, sehingga saya dapat memperbaikinya.
UPD3: Karena banyak menafsirkan istilah "bidang subjek" dengan cara yang berbeda, saya memberikan beberapa contoh bidang subjek sehingga tidak ada kebingungan dan substitusi konsep. Area subjek selalu tergantung pada masalah apa yang Anda selesaikan menggunakan pengembangan aplikasi:
- Pemesanan tiket (jika Anda adalah pengembang sistem reservasi)
- Perbankan (jika Anda adalah pengembang aplikasi perbankan)
- Sistem Operasi (Jika Anda adalah pengembang OS pengembang)
- Manajemen infrastruktur cloud (jika Anda adalah pengembang k8s)
- Virtualisasi (Jika Anda adalah pengembang Docker)
- Pemantauan Kinerja (Jika Anda adalah pengembang Prometheus / Grafana)