Ini akan menjadi cerita tentang kesan buku itu, dan juga beberapa konsep dan pengetahuan yang, berkat buku ini, dipelajari
Arsitektur
Bisakah Anda, membaca publikasi ini, memberikan jawaban yang jelas untuk pertanyaan, apa itu arsitektur? Apa itu arsitektur dalam konteks pemrograman dan desain? Peran apa yang dia mainkan? Ada banyak ambiguitas dalam istilah ini. Dan semuanya tampak jelas, tetapi entah bagaimana abstrak, dan tanpa akurasi. Martin percaya, dan saya setuju dengannya, bahwa aplikasi memiliki dua komponen:
- Behavior (behaviour) - fungsi dan tugas yang dijalankan oleh program (komponen, layanan).
- Arsitektur - istilah ini lebih tentang mengubah aplikasi.
Tetapi bahkan jika aplikasi melakukan dengan sangat baik tugas yang harus dilakukan, ini tidak berarti sama sekali bahwa ia memiliki arsitektur yang baik. Arsitektur bukan tentang perilaku aplikasi. Arsitektur adalah tentang kemudahan perubahan, arsitektur adalah tentang kemudahan penyebaran, arsitektur adalah tentang kemandirian pembangunan. Arsitektur adalah tentang kecepatan di mana pemahaman datang ke orang baru dalam tim
Dan inilah cara membangun arsitektur ini, cara menghilangkan sakit kepala dengan perubahan kecil dalam persyaratan dari PM, atau dari pemangku kepentingan: inilah yang akan diceritakan buku ini
Tentang Penulis
Sebelum saya mengatakan sesuatu tentang buku ini, saya ingin mengatakan sedikit tentang diri saya.
Saat ini, saya adalah Pengembang Junior yang Kuat yang berspesialisasi dalam mengembangkan layanan melalui ASP .NET CORE.
Saya sudah mengerjakan satu "galeri" selama satu tahun sekarang, dan sepertinya saya melakukan sedikit
Saya sudah membaca buku ini 2 kali, dan saya merekomendasikannya kepada semua orang untuk membaca:
- pengembang sistem sematan;
- endchikers depan;
- pendukung belakang;
- dan bahkan devopsam.
Secara umum, untuk siapa saja yang setidaknya entah bagaimana terhubung dengan pengembangan PP, maksud saya pengembangan langsung dari Saylov dan PM'ov yang berbeda di sini kita tidak mempertimbangkan di sini (meskipun juga akan berguna untuk mengetahui mengapa seorang pelayan terkadang menghabiskan 2 kali lebih banyak waktu untuk suatu tugas), saya menyarankan Anda untuk membaca buku ini.
Dan sekarang saya akan mencoba untuk berdebat mengapa saya berpikir begitu
Sedikit tentang penulis buku ini (karena bagi saya otoritas penulis memainkan peran besar). Saya pikir Anda akan mengerti saya, meskipun ini tidak selalu benar, tetapi jika orang yang berwibawa di bola mengatakan sesuatu kepada Anda, Anda menunjukkan lebih percaya diri pada apa yang dia katakan. Sebagai contoh, saya pikir Anda lebih suka percaya pada diagnosis yang diberikan dokter kepada Anda daripada dari beberapa orang dari kerumunan (lihat gejalanya)
Robert Martin - alias Ankle Bob (Paman Bob) - telah bekerja di bidang pemrograman, dan dari berbagai sistem (dari layanan web ke sistem embed), sejak 1970. Dia adalah konsultan teknis dan arsitek, dia menulis di berbagai jurnal teknis, dia adalah programmer yang sangat berpengalaman, dan seseorang yang memainkan salah satu peran kunci dalam menciptakan prinsip-prinsip SOLID yang terkenal (bisa dibilang pencipta). Juga, saya ingin menambahkan bahwa pemimpin tim saya dengan 15+ pengalaman menyarankan saya pada buku ini
Tentang buku itu
Ketergantungan
Sebelum membaca buku itu, saya membaca cukup banyak artikel tentang Habré yang sama, di mana kata "ketergantungan" muncul. Apa itu, siapa yang bergantung pada siapa, apa sebenarnya "bergantung pada" artinya, dan bagaimana beberapa kelas dapat bergantung pada seseorang?
Dan ketika saya membaca buku itu, saya belajar dua hal:
Ketergantungan adalah istilah yang berarti bahwa beberapa kelas (komponen, layanan) tahu tentang beberapa kelas lain (komponen, layanan), dan pengetahuan ini pada tingkat kode ditentukan (sekarang javists, penajam, orang akan mengerti saya) oleh impor namespace tertentu . Dengan kata lain: Anda memiliki kelas A dengan namespace Default.Classes dan kelas B Another.Classes. Jadi, jika kode kelas A muncul menggunakan Another.Classes; - ini berarti bahwa kelas A tergantung pada kelas B.
Untuk memahami sesuai dengan skema di mana kelas dependen berada dan di mana tidak - lihatlah arah panah: 1) panah akan menunjuk dari kelas A ke arah kelas B. Ini berarti bahwa kelas B lebih mandiri daripada kelas A. Dan perubahan di kelas A , tidak ada "kerusakan" pada kelas B
PADAT
Salah satu alasan utama untuk membaca buku ini adalah penjelasan tentang prinsip-prinsip SOLID dari sumber aslinya, karena Paman Rob mengembangkan prinsip-prinsip ini, dan kita dapat mengucapkan terima kasih kepadanya bahwa kita mendengar nama ini - SOLID.
Bagi mereka yang tidak tahu - prinsip-prinsip ini dikatakan dan disarankan untuk merancang aplikasi mereka sesuai dengan 5 aturan:
S - SRP (Prinsip tanggung jawab tunggal)
O - OCP (Prinsip buka-tutup)
L - LSP (Prinsip substitusi Liskov)
I - ISP (Prinsip pemisahan antarmuka)
D - DIP (Prinsip Ketergantungan Pembalikan)
Semua prinsip ini dapat diterapkan di tingkat kelas dan objek, di tingkat modul dan komponen, dan di tingkat rel (layanan).
Jika Anda berpikir bahwa prinsip tanggung jawab tunggal adalah tentang fakta bahwa kelas, atau modul hanya melakukan satu hal, maka Anda harus membaca setidaknya bab tentang Solid. Karena definisi yang diberikan di atas adalah konsekuensi, tetapi bukan definisi dari prinsip itu sendiri
Tentang Ketergantungan Inversi
Saya ingin memberikan perhatian khusus pada penjelasan Prinsip Ketergantungan Inversi (yang D adalah dari SOLID). Dalam membaca buku ini, saya mengerti bahwa ini bukan hanya prinsip, tetapi juga mekanisme dan alat yang dengannya Anda dapat mengubah arah dependensi Anda dan membuat, misalnya, logika bisnis (DOMAIN) terlepas dari rincian penerapan lapisan akses Data (DAL'a)
Meskipun prinsip itu sendiri bersama dengan yang lain dalam SOLID berarti sedikit sesuatu selain mekanisme, mekanisme itu sendiri digunakan di seluruh buku ini, dan ini adalah salah satu metode utama untuk membalikkan dan mengubah arah ketergantungan Anda, yang dengan cara digunakan dengan DDD
Tentang membuat keputusan arsitektur
Sangat sering, buku ini akan menyebutkan prinsip pengambilan keputusan arsitektur yang penting: basis data mana yang digunakan, kerangka mana yang digunakan, perpustakaan mana yang akan dihubungkan, apa yang harus digunakan sebagai mesin pencari, dll.
Jadi, penulis percaya: Anda harus ASAP membuat keputusan semacam ini. Karena persyaratan dapat berubah, pembatasan kinerja juga, komponen perilaku itu sendiri cenderung berubah. Selama proses pengembangan, beberapa solusi mungkin tampak kurang efektif daripada yang lain, kurang nyaman daripada yang lain. Dan kekuatan arsitektur Anda akan menentukan seberapa cepat dan tanpa rasa sakit Anda dapat mengganti satu teknologi dengan yang lainnya (OCP mengatakannya).
Misalnya, tiba-tiba, Anda memutuskan untuk menggunakan MongoDb alih-alih Postgresql, atau file secara umum, atau menggunakan data tiruan, operasi yang akan dilakukan dalam memori. Dan dalam kondisi tertentu - ini memungkinkan untuk menulis ulang hampir semua logika.
Untuk mencegah situasi seperti itu, kita dapat menggunakan beberapa mekanisme yang akan mendorong waktu pengambilan keputusan sejauh mungkin. Salah satu mekanisme ini adalah abstraksi.
Referensi DDD
DDD - Desain Didorong Domain - pendekatan untuk mengembangkan layanan dengan logika bisnis yang kompleks, penting untuk perubahan, yang bertujuan memaksimalkan pemahaman posisi manajemen proyek (PM, manajer Penjualan dll), dengan pendayung. Artinya, bahwa akan ada bahasa di mana-mana di antara semua anggota proyek, dan semua orang dapat memahami yang lain, dan bahwa setiap orang berpikir dalam domain yang sama dengan aturan bisnis yang sama.
Jika Anda adalah pendukung DDD, atau ingin menjadi DDD, atau Anda tidak memahami sesuatu tentang ini, tetapi ingin memahami, buku ini harus dibaca, terutama bagian kedua dari buku ini.
Di sini penulis menjelaskan keberadaan Aturan Ketergantungan, dan mengapa, mengikutinya, Anda akan membangun arsitektur aplikasi yang benar. Mengapa ketergantungan harus mengikuti komponen Kebijakan Tinggi, mengapa domain (komponen Kebijakan Tinggi) harus independen dari infrastruktur dan bagaimana hal itu akan menyederhanakan penyebaran dan pengembangan untuk Anda
Abstraksi
Paman Rob juga berbicara tentang bagaimana detail implementasi dapat membahayakan sistem Anda dan mencegahnya berkembang tanpa rasa sakit di masa depan.
Ingat!
DB adalah detail implementasi
Klien (Web, Ponsel, dll) - detail implementasi
Kerangka kerja adalah detail implementasi.
Diperlukan untuk mengabstraksi sebanyak mungkin dan tidak bergantung padanya, menggunakan Dependency Inversion yang dijelaskan di atas dengan antarmuka dan abstraksi, Aturan Ketergantungan dan mekanisme lainnya.
Metode untuk membangun modul
Saya terutama menyukai bagian ini sebagai pengembang layanan di ASP .NET CORE. Untuk itu menjelaskan metodologi untuk membangun arsitektur layanan terpadu dari komponen yang sudah jadi.
Robert menggambarkan 4 kemungkinan skema pemisahan lapisan.
Dia menjelaskan mengapa mekanisme arsitektur 3-layer yang sering digunakan: UI (pengontrol), Layanan (Domain), DAL (Database) - cukup buruk dibandingkan dengan yang lain. Saya belum melihat banyak proyek, tetapi di masing-masing, misalnya, layanan mikro, di bagian belakang, ia menggunakan arsitektur tiga lapis.
Juga, cukup sering, arsitektur satu komponen satu layanan digunakan. Secara umum, keduanya baik, tetapi memiliki banyak kelemahan, sebagai perbandingan, misalnya, bagaimana arsitektur dibangun menggunakan DDD, terutama ketika sangat penting untuk berubah, dan layanan yang kompleks.
Secara umum, ulasan buku ini telah berakhir. Saya sangat menyukai buku itu sendiri, saya tidak menyesali apa yang saya baca, terima kasih kepada penulis. Terima kasih atas perhatian Anda, pembaca yang budiman, jangan menilai dengan ketat - publikasi ini didasarkan pada kesan buku dan antusiasme pribadi saya
PEMBARUAN 1.0
Selama diskusi, dapat dipahami bahwa perubahan penyimpanan SUDDEN dan MUDAH tidak akan mudah, dengan satu atau lain cara. Dalam beberapa kasus, bahkan abstraksi yang sangat menyakitkan, namun enkapsulasi akses ke toko, diragukan apa yang akan membuat situasi lebih buruk, tetapi sedikit lebih baik, setidaknya karena independensi komponen variabel dari yang lain.