Pendahuluan
Saya ingin berbicara tentang pengalaman menerapkan praktik DDD ke proyek Ruby on Rails yang ada. Awalnya, kami memiliki monolith yang ditulis selama 10 tahun. Kesulitan utama dari proyek ini adalah dalam proses yang agak rumit, dan konektivitas tinggi. Kami berhasil tidak hanya menguraikan aplikasi menjadi layanan yang terpisah, tetapi juga secara signifikan meningkatkan keterbacaan kode, membuat proses yang dijelaskan transparan.
Pemecahan masalah dalam sistem menjadi dapat diprediksi, kami berhenti bekerja dengan kotak hitam, dan pada akhirnya, sistem itu sendiri mulai memberi kami solusi.
Untuk memfasilitasi persepsi dan penulisan, sebuah cerita tentang pendekatan yang digunakan akan disajikan dalam bentuk serangkaian artikel. Pendekatan ini bukan "peluru perak", jadi saya ingin menyoroti terlebih dahulu semua segmen proyek yang dapat ditampung oleh solusi ini. Lebih lanjut, saya akan berbicara lebih detail tentang metodologi DDD dan implementasi layanan mikro dari pola ini, saya akan menjelaskan kemungkinan kombinasi dari pola yang diterapkan dengan mempertimbangkan implementasinya, dan pada akhirnya saya akan memberikan contoh implementasi spesifik dari satu layanan kecil.
Tesaurus
Tesaurus adalah glosarium istilah yang digunakan untuk menggambarkan bidang subjek tertentu.
Semua definisi yang akan diperkenalkan di bawah ini adalah benar dalam kerangka kerja artikel ini. Anda dapat menerapkannya pada bidang subjek Anda jika mereka menggambarkannya dengan cukup baik.
Masalahnya dipecahkan dalam kerangka pendekatan ini
Pendekatan yang diuraikan di bawah ini memiliki spesialisasi yang agak sempit, dan, di atas segalanya, ditujukan untuk menyelesaikan masalah tertentu. Namun demikian, ini tidak mengecualikan minat yang mungkin dari spesialis di bidang terkait. Jadi, kami memiliki tugas:
Anda perlu menulis ulang dan memelihara proyek dengan logika bisnis yang rumit yang ditulis dalam Ruby on Rails, dengan sumber daya yang memadai.
Mari kita tulis tugas ini secara lebih rinci.
Mengapa ada kebutuhan untuk menulis ulang proyek?
Saya pikir setiap pengembang dapat menjawab pertanyaan ini. Lebih sulit dijawab sehingga jawaban ini memuaskan kebutuhan bisnis Anda.
Kami menggunakan definisi Bisnis , seperti yang diterima secara umum, meskipun kami akan berinvestasi dalam istilah ini konsep yang lebih luas - perusahaan (sesuatu yang dilakukan oleh sekelompok orang), pekerjaan (sibuk).
Bisnis adalah upaya sebuah perusahaan yang terdiri dari orang-orang, yang diekspresikan melalui tindakan yang bertujuan untuk memperoleh manfaat bagi berbagai individu.
Sebagai contoh:
- Perusahaan membuat produk untuk konsumen atau menyediakan layanan.
- Laboratorium sedang mengembangkan obat baru.
- Sekolah terlibat dalam pelatihan.
- Arsip kota menyediakan informasi kepada warga.
- Lera menyenangkan para penggemarnya dengan sosok yang luar biasa di jejaring sosial.
Dalam kasus massal, sebuah bisnis dibangun di sekitar gagasan untuk menghasilkan keuntungan dengan memuaskan kebutuhan pelanggannya. Agar laba dapat ditingkatkan, perlu untuk memenuhi kebutuhan aktual klien dengan sejumlah besar solusi berkualitas. Ide ini digambarkan sebagai prinsip pertama dari manifest Agile, meskipun ide itu tidak baru. Fakta yang mendasari kebutuhan masyarakat kita telah diperdebatkan oleh banyak filsuf. Misalnya, Plato mencoba merampingkan kebutuhan, membuat klasifikasi mereka. Dialah yang menyebutkan bentuk-bentuk utama kebutuhan ekonomi: makanan, pakaian, perumahan. "Tantangan bisnis" adalah untuk memenuhi kebutuhan. Dan solusi yang diterapkan harus meningkatkan daya saing bisnis.
Daya Saing - Keuntungan satu bisnis di atas yang lain.
Manifesto Agile juga memberi kita petunjuk bahwa fleksibilitas proyek ditingkatkan melalui keunggulan teknis dan kualitas desainnya.
Pertimbangkan rantai nilai pasokan pada contoh "proyek web Khas"
- t 0 - kami punya ide.
- t 1 kami menerapkan MVP . Di sini kita sedikit ngelantur:
Produk minimum layak MVP - produk yang memiliki fungsi minimum, tetapi cukup untuk memuaskan konsumen pertama. Tugas utama adalah untuk mendapatkan umpan balik untuk pembentukan hipotesis untuk pengembangan produk lebih lanjut.
Istilah ini dipopulerkan oleh Steve Blank dan Eric Rees. MVP adalah alat yang efektif untuk menguji ide bisnis Anda dan menjawab pertanyaan utama "Lepas landas - tidak lepas landas?"
- t 2 - Kembali ke jadwal. Idenya berhasil, kami menerima umpan balik positif dan mampu memenuhi sejumlah besar kebutuhan pelanggan pada waktu yang ditentukan.
- t 3 - Kali ini, kepuasan mencapai tingkat yang lebih rendah. Kami telah menambah staf.
- t 4 - Kami memberikan nilai lebih sedikit.
- t 5 - Jika kami tidak memulai Refactoring, maka saat ini bisnis tidak lagi kompetitif.
Mengapa ini terjadi? Seiring waktu, proyek kami mengakumulasi tingkat entropi yang tinggi karena konektivitasnya yang tinggi. Misalkan kita memiliki "Perusahaan Khas" yang terdiri dari departemen pemasaran, analisis, logistik, penjualan, dan manajemen. Saat ini, proyeknya adalah sebagai berikut:
Saya ingin segera membuat reservasi bahwa konektivitas tidak selalu menjadi penyebab entropi, tetapi muncul jika sistem dengan sejumlah besar proses bisnis yang kompleks diimplementasikan.
Entropi dalam kode akan selalu terjadi jika proses bisnis di perusahaan tidak terbentuk dengan benar. Apa yang mungkin menjadi karakteristik dari kedua perusahaan muda, yang berada di awal jalan mereka, juga merupakan karakteristik dari perusahaan besar, di mana tidak mungkin untuk mensistematisasikan semuanya sekaligus. Ini adalah proses alami dan kita seharusnya tidak menghalangi jalannya, tetapi menerimanya dan menggunakannya. Mari kita kembali ke grafik pertama dan melihatnya dari sisi lain:
Integral (area di bawah garis) akan menjadi uang yang diperoleh. Aplikasi nyata (Aplikasi nyata) akan menghasilkan lebih dari "ideal" (aplikasi Academin), setidaknya sampai permulaan entropi - t 4 . Kedengarannya bagus, dan itulah yang perlu Anda lakukan.
Tapi apa yang harus dilakukan di masa depan? Mengulangi refactoring hingga tak terbatas tidak mungkin. Pada titik waktu tertentu, volume basis kode akan mencapai tingkat tertentu sehingga sulit untuk menulis ulang “sekaligus”. Dan cepat atau lambat akan perlu untuk memecah proyek menjadi komponen yang terpisah:
Salah satu pendekatan untuk mengimplementasikan sistem yang kompleks adalah DDD:
Domain-driven design (DDD) adalah pendekatan untuk mengembangkan perangkat lunak untuk kepuasan kebutuhan yang komprehensif, dengan secara ketat menghubungkan implementasi dengan model bisnis utama yang sedang dalam proses pengembangan konstan.
DDD adalah serangkaian praktik dan definisi yang akan dijelaskan secara lebih rinci di artikel selanjutnya. Pola sentral dari pendekatan ini adalah Bounded Context , intinya adalah bahwa setiap area subjek terdiri dari beberapa set model yang tidak boleh berkomunikasi dengan dunia luar, serta model yang digunakan di dunia luar dalam hubungannya dengan konteks terbatas lainnya. Setiap konteks terbatas memiliki antarmuka yang jelas di mana ia memutuskan model mana yang akan digunakan bersama dengan konteks lain.
Pola ini dapat diimplementasikan melalui namespace (namespace), dan melalui layanan microser. Kami akan menggunakan kedua implementasi ini, tergantung pada tingkat konektivitas konteks. Yang pada akhirnya mengarah pada pembuatan aplikasi yang terurai dan tersegmentasi.
Grafik di atas tidak mungkin mencerminkan gambaran nyata, tetapi memungkinkan Anda untuk membandingkan berbagai pendekatan di antara mereka sendiri.
Dukungan proyek
Sebagai bagian dari dukungan proyek, sejumlah hal perlu disediakan.
- Nilai pengiriman : Scrum, Agile, layanan pelanggan, pengiriman berkelanjutan.
- Pengurangan entropi : DDD, Mikro-layanan sebagai salah satu cara untuk memisahkan konteks, dokumentasi.
- Kualitas kode : Desain level domain, TDD, BDD.
- Kualitas produk : Pengujian manual dan otomatis, pelacakan bug, pencatatan.
- Ketersediaan Produk : Sistem Duplikasi.
- Kecepatan Produk : Penskalaan Horizontal.
- Retensi tim pengembangan : Sistem motivasi, keterbukaan, kejujuran.
Seperti yang Anda lihat, mempertahankan sistem yang kompleks membutuhkan banyak sumber daya. Pertama-tama, personel yang sangat berkualitas. Sebelum menggunakan teknologi ini atau itu, pikirkan apakah Anda memiliki kesempatan untuk memberikan dukungannya pada tingkat yang tepat.
Harus diingat bahwa ambang untuk memasuki sistem yang kompleks cukup tinggi, jadi penting untuk memberikan pelatihan bagi personel. Juga, jika kita ingin bekerja tanpa kegagalan, kita seharusnya tidak memiliki spesialis yang "tidak tergantikan", dan oleh karena itu perlu untuk memastikan pertukaran semua peran yang penuh. Jika Anda memiliki 'Spesialis pengiriman kontinu' yang terbang keluar dari tim, Anda perlu menggantinya. Jika penggantian tidak dapat diberikan, maka tidak layak memperkenalkan tumpukan teknologi ke dalam "produksi" tanpa memberikan dukungan yang memadai.
Ini bukan tentang spesialis di tingkat yang sama. Biarkan Anda memiliki DevOps terkemuka dan pengembang tertentu untuk siapa topik ini menarik (disebut "multiclass"). Baginya, seperti untuk "biola kedua", penting untuk memberikan pemahaman di mana dan bagaimana menemukan alat untuk memecahkan masalah. Untuk ini, setidaknya seperempat dari total volume tugas yang masuk terkait dengan spesialisasi baru harus didistribusikan kepadanya. Tugas-tugas ini akan dilakukan secara perlahan, biaya akan meningkat, tetapi di masa depan ini akan mencegah risiko gangguan dalam penyediaan nilai karena kekurangan personel.
Hal-hal seperti itu dijelaskan dalam persyaratan Scrum, saya tidak ingin memikirkannya. Satu-satunya hal yang saya ingin menarik perhatian Anda, apa yang perlu Anda siapkan, adalah biaya besar yang akan dihabiskan untuk mendukung proyek Anda. Jika bisnis Anda tidak siap untuk ini, dan Anda mulai menggunakan banyak alat mahal, Anda akan merusak bisnis.
Secara singkat
- Jika Anda perlu menerapkan MVP , mulailah dengan Ruby On Rails.
- Jika MVP lepas landas dan idenya dibenarkan, lakukan refactoring pertama, "meringankan" model Anda dengan layanan, dekorator, menghapus lapisan validasi dan basis data dari model menjadi masalah terpisah. Tulis tes, dokumentasi.
- Jika Anda tidak memiliki proyek yang sedemikian rumit dan Anda dapat menghapus entropi dengan mengoptimalkan model - lakukanlah.
- Jika Anda memiliki proyek yang logis dan mudah dibaca, dan Anda perlu meningkatkan produktivitasnya, sementara itu dapat dibagi, katakanlah, oleh pengguna, kemudian gunakan penskalaan. Tetapi jangan mencoba memecah proyek menjadi layanan dengan domain.
- Jika Anda memiliki bisnis "kompleks" dan Anda sedang mencari alat untuk daring (mengapa Anda belum melakukannya ?!) - juga pertimbangkan "solusi Perusahaan" yang sudah jadi, katakanlah, di java atau .NET. Praktik yang dijelaskan berasal dari solusi semacam itu dan mereka memiliki toolset yang kaya, yang akan menghemat uang Anda.
- Jika proyek Anda menggunakan ruby, Anda memiliki staf programmer ruby, proyek tersebut berisi logika bisnis yang kompleks, sedang bersiap untuk memuat atau sudah dimuat, dan entropi telah berkembang sedemikian rupa sehingga sangat, sangat sulit untuk ditulis ulang, maka Anda harus mempertimbangkan untuk menggunakan pendekatan DDD dan pendekatan Microsoft.
Lain kali saya ingin mempertimbangkan secara lebih rinci esensi dari pendekatan DDD dan implementasi layanan-mikronya.
Sumber inspirasi: