Gambar dari blog tomaszjaniak
Tunjukkan Arsitektur Anda
Kebetulan Anda telah mengerjakan sebuah proyek selama beberapa tahun dan saat ini Anda duduk di atas siku Anda dalam kode, tes terbakar, pendingin laptop mengeluarkan suara, mencoba mendinginkan panas prosesor yang terlalu panas oleh kompiler, hanya beberapa jam lagi - dan pemfaktoran ulang akan selesai. Dan kemudian kita harus segera meninggalkan semuanya dan menggambar Arsitektur proyek. Klien besar direncanakan, dan untuk menutup kesepakatan, perlu menjalani audit. Dan dalam hal ini, tidak ada tempat tanpa Diagram Arsitektur. Jadi bagaimana jika proyeknya masih kecil, dan belasan pengembangnya dalam pekerjaan nyata tidak membutuhkan Arsitektur apa pun di sana. Ini kodenya - semuanya jelas. Tapi tidak ada jalan keluar. Itu perlu - maka itu perlu.
Jika Anda tahu bagaimana semuanya bekerja, arsitektur produk apa pun dapat dibuat dalam satu jam. Dan ini biasanya cukup untuk audit. Bagaimanapun, inti dari audit bukanlah agar pihak luar benar-benar memahami arsitektur produk Anda. Inti dari pertanyaan ini adalah untuk menentukan apakah pengembang produk itu sendiri memiliki pemahaman tentang apa yang mereka lakukan. Dan jika Anda berbicara dengan cukup percaya diri dan menjawab pertanyaan tanpa ragu, semuanya akan berjalan lancar. Tapi tetap saja, ketika cerita ini berakhir, di suatu tempat di kedalaman cacing akan menetap, yang akan mempertajam pertanyaan: tapi tetap saja, jenis Arsitektur apa yang sebenarnya dimiliki produk tersebut? Lagi pula, jika mereka bertanya, mungkin orang lain memiliki Arsitektur. Dan jika kita tidak memilikinya, ini jelas berantakan. Ada keinginan besar untuk melakukan semuanya dengan baik agar dapat bertanggung jawab atas Arsitektur di waktu mendatang sebagaimana mestinya.
Bagaimana Anda melakukannya dengan benar? Anda perlu menggambar diagram, mendeskripsikan fitur dalam dokumen, dan kemudian selalu memperbarui semua ini. Maka itu akan menjadi Arsitektur. Tetapi, setelah mempresentasikan jumlah pekerjaan, segera muncul pemahaman bahwa semua ini tidak sebanding dengan waktu yang dihabiskan. Ini kodenya - semuanya jelas. Dan jika klien lain datang, maka dalam satu jam lagi dimungkinkan untuk menggambar diagram baru.
Dan setelah beberapa tahun, Anda mungkin menemukan diri Anda dalam situasi yang berlawanan, dan dokumen yang akan menjelaskan arsitektur produk lain tidak akan lebih baik. Tentu saja, penting untuk mengetahui bahwa orang lain juga memiliki arsitektur yang sangat buruk. Tetapi ketika ukuran proyek mulai diukur dalam jutaan baris kode, dan jumlah pengembang ratusan, pertanyaan tentang kebutuhan Arsitektur masih menjadi signifikan.
Di sini, dalam kerangka alur kerja, berbagai diagram Arsitektur mulai muncul, Proposal Arsitektur mulai menulis tentang fitur, semua ini dibahas, ditinjau, divalidasi, disetujui dan, tentu saja, menjadi usang bahkan sebelum proses ini selesai. Tidak perlu dikatakan bahwa dokumen seperti itu mencerminkan struktur sebenarnya dari kode aplikasi. Dan ketika sampai pada implementasi, kebetulan pengembang tidak membaca dokumen ini sama sekali. Atau sesuatu yang sama sekali berbeda dari apa yang tertulis sedang dilaksanakan. Seseorang salah paham, atau mendesak untuk melakukannya, dan tidak ada waktu untuk berdiskusi.
Mungkin semuanya sebagaimana mestinya. Mungkin, Arsitektur adalah Birokrasi di sekitar dokumen spekulatif, terpisah dari kenyataan? Tetapi intuisi memberi tahu kita bahwa bagaimanapun juga, tidak. Jadi, apa itu "Arsitektur"?
Arsitektur adalah ...
Apa yang terjadi jika Anda mengajukan pertanyaan "Apa itu Arsitektur?" sepuluh pengembang profesional? Jika Anda tidak membuka Wikipedia, apakah mereka akan memberikan jawaban yang sama?
Arsitektur adalah sekumpulan keputusan penting, dan struktur elemen, dan antarmuka mereka, dan sistem ketentuan, aturan dan perjanjian, dan pendekatan yang dibentuk yang menjaga ketertiban, dan solusi untuk masalah global, dan dekomposisi dengan interaksi, dan deskripsi tingkat tinggi dari sistem, dan siklus hidupnya. bagian, dan pola struktur dan perilaku, dan apa yang sulit atau mahal untuk diubah atau dihilangkan, dan keputusan dan pertukaran fundamental, dan banyak lagi.
Arsitektur juga merupakan cara aplikasi memenuhi tujuannya.
API adalah Arsitektur, skema data juga merupakan Arsitektur, dan struktur modul dan layanan. Ada Arsitektur Penskalaan Aplikasi, Arsitektur Keandalan Aplikasi, Arsitektur Interaksi Komponen, dan Arsitektur Keamanan. Dan tentunya, setiap fitur memiliki Arsitekturnya sendiri-sendiri. Dan semua ini juga merupakan Arsitektur.
Dapatkah semua ini dianggap sebagai jawaban atas pertanyaan "Apa itu Arsitektur?" - mungkin ya. Segalanya tampak benar, semuanya tampak jelas. Tetapi apakah jawaban ini praktis berguna, sesuatu yang dapat digunakan dalam alur kerja nyata? Tidak juga.
Bagaimana Anda tahu jika keputusan itu penting atau fundamental? Apa tantangan global? Apa artinya mahal atau murah? Bagaimana Anda memperkirakan kompleksitas? Di manakah batas antara tingkat tinggi dan tingkat rendah? Apa urutannya? Apa tujuan dari sistem ini?
Ini semua adalah pertanyaan yang juga bisa Anda coba jawab. Merumuskan definisi, menjelaskan dengan contoh, paling buruk, mengatur proses pengambilan keputusan. Tetapi itu akan tetap menjadi sesuatu yang kontroversial, sesuatu yang intuitif, tergantung pada persepsi pribadi dan sedikit dipahami oleh setiap orang dengan caranya sendiri. Artinya, akan selalu ada konflik berdasarkan fakta bahwa orang yang berbeda menafsirkan situasi yang sama dengan cara yang sangat berbeda. Pengembang akan mengeluh bahwa arsitek merusak detail implementasi, arsitek yang melanggar Arsitektur. Jika tidak ada batasan yang jelas, konflik tidak bisa dihindari.
Setiap orang mungkin memiliki pemahaman umum tentang apa itu Arsitektur. Tetapi sulit untuk menyebutkan definisi tunggal, yang diverifikasi secara formal dan tepat secara matematis.
Di sisi lain, jika Anda bertanya "Apa itu Realisasi?" - jawabannya mungkin tidak ambigu: "Ini adalah tautan ke repositori kode!" Dan Anda tidak bisa membantahnya. Dan tidak ada keraguan atau ambiguitas dalam penafsiran jawaban ini. 1 + 1 = 2, Implementasi adalah kode.
Dan sangat mudah untuk bekerja dengan kode. Jika Anda ingin memahami implementasinya, Anda dapat membuka proyek di lingkungan pengembangan. Jika perubahan kode perlu ditinjau, maka ada cabang di repositori. Jika sudah waktunya untuk merilis versi baru aplikasi, pengujian akan diluncurkan.
Tentu saja, struktur proyek dapat membingungkan, kualitas tinjauannya buruk, dan cakupan tes tidak lengkap. Tapi, setidaknya ketika bekerja dengan kode, selalu jelas apa dan kapan harus dilakukan.
Tetapi bagaimana jika Arsitektur diekspresikan dalam kode, seperti Implementasi?
Banyak bahasa pemrograman utama digunakan dalam perkembangan modern. Kebanyakan dari mereka muncul lama sekali atau sangat lama. Dan meskipun mereka masih bagus, mereka sedikit ketinggalan zaman. Ini adalah bahasa yang diketik dengan lemah: JavaScript, Python, PHP, Ruby, dan bahasa yang sangat diketik: Java, C / Objective-C / C ++, C #. Mereka digantikan oleh bahasa baru yang, dalam kerangka platform yang sama, mencoba memecahkan masalah lama, menaburkannya dengan gula sintaksis, tetapi tanpa memperkenalkan konsep baru yang fundamental, jika Anda melihat secara global: Swift, Kotlin, TypeScript, Go. Ini semua adalah bahasa yang dibangun di atas paradigma Berorientasi Objek. Juga, pendekatan Fungsional untuk pemrograman telah mendapatkan popularitas yang matang, yang diimplementasikan dalam bahasa yang terdaftar dan disajikan dalam bahasa khusus, tetapi kurang populer: Erlang, F #.Bahasa yang menerapkan konsep baru secara substansial juga mulai mendapatkan popularitas: Rust, Haskell.
Semua keragaman ini memiliki satu kesamaan: semuanya adalah bahasa Implementasi. Tak satu pun dari bahasa pemrograman ini merupakan ekspresi Arsitektur. Tetapi ada satu pengecualian - SQL.
SQL adalah satu-satunya bahasa pemrograman utama yang bersifat Deklaratif. Itu dibangun di atas model aljabar relasional dan memiliki spesialisasi yang sempit - bekerja dengan data yang disimpan. Tapi tetap saja, mengapa SQL bisa dianggap sebagai bahasa Arsitektur?
Pertama-tama, SQL memberikan akses ke informasi meta tentang skema data. Anda bisa dengan mudah mendapatkan daftar tabel, kolom, hubungan, indeks, tampilan, peran, dan lainnya dari database. Dokumentasi skema penyimpanan dan kemampuan untuk memvisualisasikannya sangat membantu dalam memahami struktur aplikasi. Deskripsi skema data adalah jenis deskripsi arsitektur tingkat tinggi.
Kedua, SQL menyediakan bahasa kueri data yang memungkinkan klien untuk menanyakan kombinasi data apa pun yang dijelaskan dalam skema. Jika tidak ada bahasa kueri, maka untuk setiap model data yang diperlukan oleh klien, metode API terpisah harus diterapkan, atau klien harus membuat beberapa panggilan API ke bagian berbeda dari skema data dan menggabungkan model yang diperlukan di sisinya. Kehadiran bahasa kueri memungkinkan untuk mengecualikan dari deskripsi detail implementasi Arsitektur yang terkait dengan enumerasi metode API untuk mendapatkan model data tertentu sesuai dengan skema umum. Bahasa kueri mengecualikan detail implementasi dari deskripsi Arsitektur.
SQL menyediakan tiga properti utama yang penting untuk menjelaskan Arsitektur:
- Deklaratif - SQL memungkinkan Anda memisahkan deskripsi Arsitektur dari Implementasinya.
- Analyzeability - SQL menyediakan akses ke meta-informasi dari skema data, yang memungkinkan Anda untuk memvisualisasikan, mendokumentasikan dan menganalisis representasi.
- Ketepatan - SQL memungkinkan Anda untuk menentukan batasan model data, yang memungkinkan untuk mencegah berbagai pelanggaran integritas data oleh Implementasi.
Mungkin, SQL dapat disebut sebagai alat untuk mendeskripsikan Arsitektur dalam hal penyimpanan data, tetapi ini jelas tidak cukup untuk menggambarkan Arsitektur lengkap suatu produk.
Cara lain untuk menggambarkan Arsitektur
Analog langsung dari SQL adalah GraphQL, yang juga memungkinkan Anda untuk menentukan skema data dan menyediakan akses ke sana melalui bahasa kueri. Pada saat yang sama, GraphQL dibangun di atas teori grafik, bukan pada model aljabar relasional. Hal ini memungkinkan untuk bekerja dengan model data hierarki dengan cara yang lebih alami, berbeda dengan SQL, di mana bekerja dengan hierarki bisa jadi sulit.
GraphQL sering dipromosikan sebagai solusi komunikasi klien-server, tetapi ini bukan satu-satunya area aplikasinya. Demikian pula, melalui GraphQL, Anda dapat menyediakan komunikasi server-ke-server, dan bahkan komunikasi server-ke-basis. Fakta bahwa database modern hanya menyediakan antarmuka SQL, tetapi tidak menyediakan API yang nyaman untuk bekerja dengan kueri hierarki adalah kelalaian yang menghina.
Jika SQL adalah sarana untuk mendeskripsikan Arsitektur skema penyimpanan data, maka GraphQL memungkinkan Anda untuk mendeskripsikan Arsitektur skema data yang sudah ada di tingkat bisnis, dalam hal area aplikasi tertentu. Dalam pengertian ini, GraphQL memungkinkan Anda untuk mendefinisikan Arsitektur di tingkat yang lebih tinggi, lebih dekat ke area aplikasi produk yang sebenarnya.
Modul kode dan layanan mikro, bersama dengan API dan dependensinya, juga merupakan sarana untuk mengekspresikan Arsitektur dalam hal struktur dan hubungan.
Arsitektur dan Implementasi
Untuk proyek kecil dengan selusin pengembang yang sedang mengerjakan, deskripsi terpisah tentang Arsitektur seringkali tidak diperlukan. Jika kode proyek ditulis dengan rapi dan terstruktur dengan baik, ini mungkin cukup untuk memahami gambaran keseluruhan dan arah pembangunan.
Seiring pertumbuhan proyek, berbagai dokumen muncul, yang menjelaskan Arsitektur umum dan detail bagian baru serta peningkatan besar. Ini adalah pendekatan yang berhasil ketika beberapa lusin orang mengerjakan sebuah proyek.
Tetapi untuk proyek yang cukup besar, ketika ada ratusan pengembang, pendekatan ini mulai gagal. Ada terlalu banyak dokumen, dan isinya mulai semakin menyimpang dari Implementasi. Menjadi semakin sulit untuk mengungkapkan pikiran dengan cara yang sama untuk semua. Demonstrasi untuk lusinan orang diselenggarakan untuk membahas banyak topik pribadi, sementara perubahan yang sangat penting dapat dilaksanakan tanpa diskusi sama sekali. Semua ini mengarah pada kebutuhan untuk mengatur lebih banyak dan lebih banyak proses, ketika beberapa harus menawarkan sesuatu, yang lain mengikuti, yang lain meninjau, dan yang lain melakukannya. Birokrasi. Akibatnya, pengembang mulai menulis lebih banyak dokumen dan lebih sedikit kode, dan ini bukanlah masalah yang paling signifikan.
Tentu tidak ada yang salah dengan birokrasi seperti itu. Dalam pekerjaan apa pun, pengorganisasiannya penting. Masalahnya adalah jumlah Birokrasi per unit kerja yang bermanfaat. Jika, untuk membuat Satu, Anda perlu mengadakan dua lagi, Tiga, Empat, Lima aksi unjuk rasa, ini tidak lagi bagus di mana pun.
Bahkan pertanyaan sederhana tentang perubahan apa yang bisa dilakukan pengembang sendiri, karena ini adalah Implementasi, dan tentang apa yang perlu membuat permintaan tinjauan, karena ini adalah Arsitektur, mulai menimbulkan kesulitan. Anda harus menemukan berbagai pemicu Arsitektur, bahwa jika Anda mengubah skema data atau menyentuh masalah kriptografi dan keamanan, ini perlu ditinjau secara Arsitektur, dan topik lain sepertinya tidak demikian, tetapi ini tidak pasti. Semua ini tidak hanya perlu dirumuskan dan dijelaskan kepada ratusan pengembang, tetapi juga untuk memastikan bahwa aturan yang dijelaskan diikuti. Proses seperti itu akan selalu gagal.
Semua masalah ini terkait dengan kurangnya definisi yang jelas tentang Arsitektur.
Sama seperti mengubah file ".java" dalam repositori secara jelas menunjukkan perubahan dalam implementasi, mengubah file ".architecture" dapat menunjukkan perubahan dalam arsitektur. Tentu saja, file ".architecture" tidak ada di alam. Tetapi untuk setiap proyek, Anda dapat menentukan aspek spesifik mana yang terkait dengan arsitekturnya, dan membuatnya eksplisit.
Jika perubahan dalam skema data dianggap sebagai perubahan dalam Arsitektur, maka file yang berisi migrasi SQL harus merujuk ke Arsitektur. Jika API juga merupakan bagian dari Arsitektur, Anda dapat mendefinisikan API dalam bentuk file swagger yang sama, dan mengandalkannya. Jika struktur modul adalah Arsitektur, maka perubahan pada deskripsi modul adalah perubahan Arsitektur. Dll
Tidak semua aspek Arsitektur dapat diungkapkan dengan cara standar. Setiap proyek memiliki spesifikasinya sendiri. Misalnya, jika produk menggunakan model khusus dari hak, peran, jenis langganan, add-on, dan sebagainya, maka Anda harus berpikir tentang mendefinisikan Arsitektur dari aspek produk ini dalam beberapa bentuk Deklaratif yang sesuai, sehingga menyoroti esensi Arsitektur dari detail implementasi. Tentu saja, perubahan tersebut mungkin memerlukan pengerjaan ulang kode yang signifikan. Tetapi ini adalah investasi yang jauh lebih baik dalam mendefinisikan Arsitektur Produk daripada mencoba menggambarkan model haknya dalam sebuah dokumen.
Representasi formal Arsitektur dalam kode dimungkinkan, dan hanya ini yang memberikan definisi yang jelas tentang apa itu Arsitektur. Tampilan ini memungkinkan untuk menganalisis Arsitektur dan secara otomatis menghasilkan dokumentasi di dalamnya, yang akan selalu up-to-date. Sisanya: dokumen, diagram, dan diagram dibuat dengan tangan - Birokrasi.
Arsitektur dapat memiliki ekspresi formal dalam kode, dan hanya ini yang menentukan batas yang jelas antara Arsitektur dan Implementasi. Dan perbatasan seperti itu dibutuhkan.
Teknik dan Pendekatan Evolusioner dalam Arsitektur
Selama setengah abad terakhir, industri pembangunan telah berkembang pesat dari model air terjun ke pengembangan berulang. Dan sekarang tampaknya industri telah melangkah terlalu jauh dalam hal ini. Di beberapa tempat, pekerjaan seorang arsitek tidak lagi menyerupai seorang insinyur atau bahkan seorang tukang kebun, dan semakin banyak yang mulai menyerupai pekerjaan seorang pekerja musiman yang disewa hanya untuk tujuan menyiangi tempat tidur dari gulma.
Yang membedakan teknik dari kriya adalah pemahaman tentang hukum alam, hukum yang menjadi dasarnya seseorang dapat membuat perhitungan dan kesimpulan, solusi desain, dan bukan eksperimen. Setiap tukang kayu dapat membuat bangku yang dapat diterima dengan sempurna, tetapi pengetahuan teknik diperlukan untuk membuat bangku tersebut optimal: ringan, andal, stabil, sederhana dan murah untuk diproduksi. Pendekatan teknik memungkinkan Anda mendapatkan hasil optimal dengan cepat dan dengan sedikit usaha. Sayangnya, dalam pengembangan perangkat lunak, pendekatan teknik tidak selalu memungkinkan.
Seringkali hasil yang ingin dicapai seseorang sangat samar-samar didefinisikan, banyak faktor yang secara signifikan mempengaruhi arsitektur solusi tidak jelas atau tidak diketahui sama sekali, dan pengerjaan implementasi solusi itu sendiri dapat lebih cepat dan lebih murah daripada elaborasi rinci arsitekturnya. Inilah salah satu alasan mengapa pendekatan iteratif untuk pembangunan mendapatkan popularitas seperti itu. Terkadang bahkan tak terkira.
Dalam kasus terburuk, pengembangan Arsitektur dapat bermuara pada fakta bahwa setiap tim pengembangan hanya memberikan tinjauan kepada arsitek deskripsi tentang apa yang akan mereka terapkan. Dalam situasi seperti itu, pekerjaan seorang arsitek direduksi menjadi penyiangan. Dan di sini Anda belum lupa? Sudahkah Anda memperhitungkan ini? Dan ini salahnya. Apakah Anda ingin menambahkan indeks di sini? Dan iterasi setelah iterasi.
Itu perlu untuk menyiangi gulma. Tapi akan seperti apa taman jika Anda hanya melakukan ini? Hamparan bunga akan layu di bawah naungan pohon buah-buahan, stroberi dan wortel akan berganti-ganti, dan semua ini akan dilalui oleh jalan yang tak terhitung jumlahnya yang menyia-nyiakan ruang yang tersedia. Sulit untuk membicarakan Arsitektur apa pun di sini.
Agar Arsitektur muncul, seorang arsitek harus melakukan setidaknya pekerjaan tukang kebun. Buah beri dan sayuran harus ditanam secara terpisah - strukturnya, dan ke mana orang paling sering pergi, jalur harus diletakkan - koneksi. Mengamati hal-hal khusus, arsitek dapat bertindak secara proaktif, mengatur dan mensistematisasikan fitur-fitur tertentu yang muncul dalam proses Realisasi menjadi satu struktur. Seperti desain lansekap, seorang arsitek dapat membentuk jalannya peristiwa alami, memperkuat tren positif dan mencegah tren negatif.
Dan di sini kita membutuhkan definisi Arsitektur yang jelas dalam kode. Skema data, struktur modul dan layanan, API dan aturan interaksinya. Tanpa mendefinisikan alat-alat ini, arsitek akan terjebak dalam tinjauan implementasi atau berharap secara naif bahwa pengembang akan benar-benar mengikuti aturan yang dijelaskan dalam beberapa dokumen, yang tentu saja tidak akan terjadi.
Jika ada presentasi formal Arsitektur dan aturan perubahannya, ini sudah bisa disebut pendekatan Evolusioner untuk pengembangan Arsitektur. Dan itu tidak buruk. Tetapi haruskah kita dibatasi pada ini?
Ya, awalnya persyaratan mungkin terlihat tidak jelas, faktor-faktornya mungkin terlihat tidak jelas, dan sistemnya sendiri sangat kompleks sehingga lebih mudah untuk dilakukan daripada mendesain. Namun seiring waktu, hal-hal ini mulai menjadi jelas. Dengan pengalaman praktis dalam pengembangan Arsitektur, detail organisasi area aplikasinya tampak semakin jelas. Jelaslah bahwa solusi umum ini diterapkan dalam lima cara berbeda, dan pengguna menderita karena keragaman ini. Bahwa beberapa barang sudah tidak pada tempatnya dan perlu dipindahkan, sedangkan yang lain sudah ketinggalan zaman dan diganti solusi baru, sehingga perlu disingkirkan. Dan perkembangan baru berhenti terlihat begitu baru - dan kami telah menerapkan ini, dan itu. Apakah Anda ingat apa yang menyebabkan semua ini? Ayo lakukan sekarang juga agar tidak perlu mengulanginya nanti. Lagi pula, melakukannya dengan benar sekaligus biasanya lebih cepat dari yang diperlukan.Tetapi ini hanya jika Anda benar-benar tahu bagaimana melakukannya dengan benar. Dan dengan pengalaman, pemahaman seperti itu sering kali muncul.
Arsitektur yang baik bukanlah sesuatu yang tumbuh dengan sendirinya dan kemudian sedikit terorganisir, tetapi sesuatu yang holistik, simetris, dan organik. Pendekatan teknik untuk pengembangan Arsitektur dimungkinkan, hanya memahami aturan dan pola saja bisa memakan waktu.
Definisi formal Arsitektur proyek tertentu tidak harus statis. Metode API yang tidak berlaku lagi bisa dideklarasikan sebagai Deprecated, dan yang hilang bisa dideklarasikan sebagai Not Implemented. Bagian kode yang bermakna dapat ditandai untuk ditempatkan di modul terpisah. Anda dapat merencanakan untuk membagi tabel menjadi dua, atau memindahkannya ke database lain. Dll Arsitekturnya bisa diubah tanpa mengubah implementasinya. Implementasinya akan menyusul. Dan untuk mengejar lebih cepat, prosesnya bisa sedikit otomatis dengan membuat pengingat otomatis dalam obrolan tim. Dengan cara yang sama, perubahan yang dibuat oleh pengembang dalam file Arsitektur dapat secara otomatis masuk ke obrolan tim arsitektur.
Pendekatan teknik untuk pengembangan Arsitektur dimungkinkan.
Pada saat yang sama, orang tidak boleh berasumsi bahwa pekerjaan arsitek adalah sesuatu yang secara fundamental lebih baik atau lebih buruk daripada pekerjaan pengembang. Dia hanya berbeda. Pengembang, pertama-tama, bekerja dalam gaya Imperatif, sedangkan karya arsitek lebih Deklaratif. Kebetulan sulit untuk mengerjakan Arsitektur, tetapi Implementasinya adalah rutin. Itu juga terjadi sebaliknya.
Arsitektur dan desain
Istilah Arsitektur dan Desain sering digunakan secara bergantian. Anda dapat mengatakan: Arsitektur Sistem atau Desain Sistem. Secara umum, jelas tentang apa ini. Namun, terdapat perbedaan yang signifikan dalam istilah-istilah ini.
Desain, pertama-tama, berarti sesuatu yang visual, sesuatu yang dapat dibayangkan atau dilihat. Skema, diagram, model. Desain memungkinkan Anda untuk secara visual menunjukkan hubungan antara entitas, melacak rantai interaksi, melihat perbedaan struktural dan analogi.
Tetapi Arsitektur tidak hanya visual, itu dapat mencakup aturan dan batasan, kesimpulan dan perhitungan matematis. Konsep yang divisualisasikan dengan buruk.
Tentu saja keduanya penting.
Ada baiknya jika aspek penting dari arsitektur didefinisikan secara eksplisit dalam kode. Tapi ini belum cukup. Penting untuk membuat Arsitektur visual, dan prinsip-prinsip yang melekat di dalamnya otomatis.
Jika Arsitektur menyertakan skema data, harus ada representasi visualnya. Modul memiliki ketergantungan - mereka juga perlu dirender. Jika ada API, harus ada dokumentasi di dalamnya yang terkait langsung dengan struktur layanan. Dll Desain adalah representasi visual dari Arsitektur.
Jika Arsitektur memiliki prinsip tertentu, misalnya, "aplikasi klien hanya dapat mengakses jenis layanan mikro tertentu, tetapi tidak semua", maka jika ada model komunikasi, mereka dapat diperiksa secara otomatis. Demikian pula, Anda dapat mengontrol tautan antara layanan mikro dan database. Jika ada aturan tertentu untuk desain model data, aturan yang sama untuk tabel penamaan, maka mereka juga dapat diperiksa secara otomatis. Dalam perkembangannya, pemeriksaan kode otomatis digunakan, hal yang sama dapat dilakukan untuk Arsitektur. Anda dapat menulis autotests pada Arsitektur.
Kesimpulan
Pengembang modern memiliki sejumlah besar alat luar biasa yang tersedia untuk mempermudah pekerjaannya. Lingkungan pengembangan, sistem build, berbagai library dan framework, layanan infrastruktur, dan container. Pengembang tidak menulis kode di Notepad.
Arsitektur juga merupakan kode, dan untuk bekerja dengan Arsitektur ada toolkit yang kuat dan kaya seperti untuk bekerja dengan Implementasi. Google Docs bukan satu-satunya alat arsitektur yang dapat Anda gunakan, dan ini jauh dari yang terbaik. Tentu saja, jangkauan alat siap pakai yang tersedia untuk arsitek saat ini tidak seluas jangkauan alat pengembang. Dan tidak semua yang berpotensi dapat digunakan oleh seorang arsitek berhasil di luar kotak. Tetap saja, semuanya tidak terlalu buruk.
Banyak alat telah ada selama beberapa dekade, seperti SQL, Anda hanya perlu mempelajari cara menggunakannya dengan benar. Teknologi baru seperti GraphQL mulai mendapatkan daya tarik, dan mereka menawarkan harapan bahwa tugas mendeskripsikan domain bisnis akan menjadi rutin seiring waktu seperti mendeskripsikan domain penyimpanan. Alat untuk dokumentasi dan visualisasi struktur aplikasi dan API tersedia, termasuk Swagger. Anda dapat menggunakan kerangka kerja dan alat integrasi yang sama untuk menguji Arsitektur seperti yang Anda lakukan untuk menguji Penerapan.
Arsitektur - Deklaratif. Mungkin birokrasi pekerjaan dengan dokumen tidak akan pernah hilang sama sekali dari pekerjaan seorang arsitek, tapi sekarang volumenya sudah bisa dikurangi secara signifikan. Arsitektur juga merupakan kode, dan seiring waktu, alat yang tersedia untuk mengerjakan Arsitektur dapat menjadi alat yang canggih untuk mengerjakan Implementasi. Kita lihat.
-
Dmitry Mamonov,
Wrike
PS Saya memulai artikel dengan daftar pertanyaan filosofis yang, saya harap, dapat memberikan jawaban yang cukup spesifik. Setidaknya itulah sudut pandang saya. Apakah Anda menemukan sesuatu yang bermanfaat atau baru dalam artikel tersebut? Bagaimana Anda sendiri menjawab pertanyaan-pertanyaan ini? Tulis di komentar.