🏂🏾 💟 🎎 Pengembangan arsitektur proyek, kapal dan JavaScript 🧙🏿 👨🏿‍🤝‍👨🏼 🕴🏿

Sebuah cerita tentang apa yang perlu Anda pertimbangkan untuk membangun arsitektur yang berkualitas untuk proyek Anda. Cara membuatnya tidak dapat tenggelam, dan pelanggan puas.

Di bawah ini kita akan mempertimbangkan contoh-contoh kehidupan nyata dan mencoba belajar dari kesalahan orang lain. Dan di sepanjang jalan, kami akan menyusun buku rekomendasi yang berguna untuk arsitek solusi. Dalam semua cerita - tugas arsitektur yang dimulai dengan persyaratan utama klien dan disertai dengan pembekalan lebih lanjut.

Artikel ini didasarkan pada laporan oleh Alexey Bogachuk (solusi-arsitek EPAM) dari konferensi Piter HolyJS 2018 . Di bawah cutscene - video dan transkrip laporan.

Pendekatan untuk membangun arsitektur dan peran arsitek proyek

Berenang - kami tahu

Demikian kata pelaut dari kapal Swedia Vasa. Mereka baru saja berlayar, melarikan diri dari kapal yang tenggelam, yang baru saja diturunkan ke dalam air dari selokan. Apa hubungan Vasa dengan itu?

Mari kita mulai dengan cerita pendek yang membuat Anda melihat pendekatan yang sangat berbeda dalam membangun arsitektur aplikasi dan peran arsitek proyek.

Raja Swedia menandatangani kontrak dengan arsitek pembuat kapal Henrik Hubertsson. Berdasarkan ketentuan kontrak, Henrik harus membangun kapal utama - keindahan armada Swedia, kapal terbaik di Eropa. Sebagai sponsor utama, raja dan perbendaharaan ikut serta dalam koordinasi semua karakteristik utama kapal, sebagai hasilnya, pesanan dirumuskan sebagai berikut:

kapal harus menjadi yang terbesar di Armada Baltik: panjang 70 meter, lebar 10;
Anda membutuhkan tiga deck, yang akan menampung 300 tentara;
dia harus memiliki 64 senjata di atas kapal dalam dua baris;
3 tahun diberikan untuk konstruksi.

Analog dari kapal semacam itu pada saat ini tidak ada. Namun, ia sendiri juga tidak bertahan lama, tenggelam di tengah perayaan pembangunannya.

Ketika mereka mencoba mencari tahu mengapa hal ini terjadi, ditemukan bahwa tidak ada penyimpangan dari persyaratan. Ukurannya sama, jumlah senjata normal, pelaut di geladak persis jumlah yang diperlukan. Namun demikian, ini sempurna dikombinasikan dengan fakta bahwa hukum fisika tidak mengizinkan kapal semacam itu bertahan lama di atas air.

Kesalahan perhitungan arsitektural Henryk berikut ini terbukti (yang, kebetulan, bisa menghabiskan nyawanya jika ia selamat di pengadilan):

Semua pembatasan yang saling bertentangan tidak seimbang.
Tidak ada manajemen risiko, karena tidak ada yang pernah membangun kapal sebesar ini sebelumnya.
Manajemen hubungan pelanggan juga tidak ada - Henrik tidak memiliki keberanian untuk berdebat dengan raja.
Teknologi konstruksi yang digunakan salah.
Arsitek menyetujui persyaratan yang mustahil.

Sebagai hasil dari kesalahan perhitungan ini, kapal "turun" bahkan pada tahap desain. Cerita ini bersifat instruktif, karena mencerminkan pengaruh siklus arsitektur pada aplikasi yang sedang dibuat. Ada pihak yang tertarik yang merumuskan tujuan dan persyaratan, berdasarkan ini, arsitektur proyek dibangun, dan kemudian proyek itu sendiri. Kesalahan pada salah satu tahap ini mungkin bernilai seluruh proyek, dan kadang-kadang kepala / pekerjaan, Henrik Hubertsson tidak akan membiarkan Anda berbohong.

Teman yang kuat

Berapa banyak aplikasi dengan arsitektur yang salah sudah mati sebelum menulis baris kode pertama?
Siklus pengaruh arsitektur pada proyek adalah sebagai berikut:

Dari kiri ke kanan:

Ada pihak yang berkepentingan, atau pemangku kepentingan (dalam hal kapal, ini adalah raja dan perbendaharaan).
Mereka memiliki tujuan mereka sendiri (kapal pertama di Eropa).
Tujuan menentukan persyaratan (karakteristik spesifik dari kapal masa depan).
Selanjutnya, gambar, diagram, dan desain dibuat.
Konstruksi pada proyek.

Kesalahan pada salah satu tahapan ini dapat mencoret masa depan proyek Anda.

Buku Panduan Arsitek Solusi

Kami akan mempertimbangkan contoh kehidupan nyata dan mencoba belajar dari kesalahan orang lain. Pada saat yang sama, kami akan menyusun buku rekomendasi yang berguna untuk arsitek solusi. Henrik Hubertsson merasa lelah dengan kenyataan bahwa dia tidak memilikinya.

Jika kita hidup di zaman pahlawan kita, ketika kesalahan dalam arsitektur dapat dihukum mati, buku ini akan ditulis dalam darah.

Dalam semua cerita kata arsitektur (tugas) akan diberikan. Mereka akan berisi permintaan yang disederhanakan dengan persyaratan pertama dari klien, esensi dari masalah dan kesimpulan.

Cerita Clockwork milik Jimmy

Persyaratan pelanggan

Ganti solusi UI saat ini.
Memperkenalkan pendekatan baru untuk pengembangan dan implementasi solusi ini.
Butuh Pengalaman Pengguna yang lebih baik.
Pada saat yang sama, ikuti semua praktik terbaik.
Dukungan untuk berbagai platform.

Apa yang telah dilakukan

Persyaratannya sangat umum, tidak spesifik. Tidak jelas apa yang harus dilakukan semua orang dengan ini. Pada saat yang sama, tim pengembangan terletak di Minsk, dan pelanggan di Montreal. Karena kenyataan bahwa ada sanksi antara Belarus dan Kanada, pekerjaan langsung dengan Kanada tidak dapat dilakukan. Diputuskan untuk bekerja dengan pelanggan melalui kantor di Dublin. Karena semua penundaan waktu dan mediasi ini, tidak mungkin untuk menghubungi pelanggan dan akhirnya menemukan persyaratan, membuat proposal untuk implementasi.

Setelah beberapa waktu, seorang Jimmy tertentu masih mulai menjawab pertanyaan dan menjelaskan persyaratan, pengembangan proyek dimulai. Dengan bersemangat Jimmy berbagi saran, kontak diambil darinya dan korespondensi dilakukan langsung dengannya. Sebagai hasil dari pekerjaan, presentasi dibuat. Saatnya menunjukkan hasil. Sebuah konferensi diselenggarakan dengan orang-orang penting dari pelanggan, tetapi, anehnya, Jimmy tidak ada di antara mereka, dan tidak ada yang tahu siapa itu. Tentu saja, semuanya ternyata sangat berbeda dari apa yang diharapkan pelanggan. Faktanya adalah bahwa perusahaan tidak tahu tentang Jimmy, ternyata dia adalah pengembang biasa dan hanya berbagi pengalaman dan sarannya. Dia tidak membuat keputusan dan, secara umum, tidak memiliki hubungan dengan proyek sama sekali.

Apa kesalahannya? Pada tahap pertama mendefinisikan arsitektur, pemangku kepentingan tidak didefinisikan dengan benar.

Kesimpulan

Arsitektur apa pun dimulai dengan identifikasi pemangku kepentingan. Untuk mengidentifikasi mereka, ada banyak pendekatan, kami akan mempertimbangkan salah satunya - kami akan membangun matriks RACI.

Raci

Singkatan singkatan dari: R - bertanggung jawab, mereka yang akan menerapkan; A - pengambil keputusan yang bertanggung jawab; Konsultasi C (konsultasi orang bisnis); Saya menginformasikan, orang yang perlu diberi tahu. Masing-masing pihak yang berkepentingan harus ditugaskan ke satu atau beberapa kategori lain. Matriks menunjukkan peran dan tugas.

Setelah membangun matriks seperti itu, kita bisa memahami siapa para pemangku kepentingan.

Selain itu, diketahui bahwa di antara para pemangku kepentingan ada orang yang memberikan klaim palsu yang mengesampingkan proyek. Dalam hal ini, ternyata ini adalah perwakilan dari vendor lain yang tidak tertarik pada proyek. Tetapi matriks RACI tidak tahu bagaimana membedakan pelanggan seperti itu, untuk ini ada pendekatan Bawang.

Bawang

Pendekatan bawang agak berbeda dari matriks RACI.

Esensinya adalah bahwa lapisan dibangun di sekitar sistem, di mana wajah-wajah pelanggan tertentu ditunjukkan. Dalam contoh ini, pengembang, Pengembang, manajer konten akan berkomunikasi dengan sistem itu sendiri. Yang sedikit lebih tinggi dalam abstraksi adalah orang-orang dari bisnis. Ada juga regulator eksternal: media, hukum, dll. Misalnya, untuk merilis aplikasi di beberapa negara, Anda harus lulus audit yang dilakukan oleh perusahaan pihak ketiga, itu akan mengungkapkan aksesibilitas dan kualitas lain yang diperlukan dari proyek, ini adalah persyaratan dari pemangku kepentingan eksternal.

Jadi, kami menulis di buku pegangan arsitek kami bahwa tahap pertama dan perlu adalah menentukan pemangku kepentingan.

Sejarah: tidak cukup cepat

Perusahaan memiliki klien dari perdagangan, dalam hal ini kecepatan transaksi sangat penting. Berdasarkan ini, sejumlah persyaratan dirumuskan.

Persyaratan pelanggan

Lebih cepat dari pesaing

Penting untuk melakukan transaksi dalam waktu tidak lebih dari 0,5 detik.

Apa yang terjadi

Proyek selesai, tetapi gagal. Mengapa Sekali lagi, persyaratannya tidak sepenuhnya benar. Tujuannya bukan untuk melakukan transaksi pada kecepatan 0,5 detik, tetapi untuk membuatnya lebih cepat dari pesaing. Hasilnya, kecepatan dibawa ke 0,5 detik, tetapi pesaing pada saat itu mencapai angka 0,4 detik. Kami melihat kesalahan dalam menentukan tujuan bisnis. Mengapa pelanggan membutuhkan suatu sistem?

Sasaran bisnis hanyalah puncak gunung es, di belakangnya adalah penggerak bisnis, pengatur, dan sasaran internal perusahaan. Seringkali mereka tetap tidak dikenal. Kami lebih tertarik pada tujuan teknis, yang mencakup tujuan bisnis. Mereka diatur oleh prinsip-prinsip bisnis, misalnya, tidak ada yang mau mengorbankan kualitas pekerjaan ketika menerapkan tujuan teknis, karena ini adalah kesalahan perhitungan dalam jangka panjang. Semua ini perlu Anda ketahui dan perlu diingat saat membangun arsitektur. Serta fakta bahwa proyek tanpa tujuan pada awalnya mati.

Kesimpulan

Bahkan jika Anda bekerja di perusahaan rintisan, tujuannya, seringkali, adalah untuk menguji teknologi baru, toh penggunaan teknologi baru dalam proyek tersebut bukanlah tujuan bisnis. Masalahnya adalah jika tujuannya adalah untuk menggunakan teknologi baru, proyek akan terus tumbuh dan membutuhkan investasi sementara dan finansial baru yang tidak perlu. Sasaran bisnis tidak boleh diabaikan ketika mendesain arsitektur.

Anda dapat menemukan rekomendasi yang berguna dalam buku "Persyaratan Menemukan", penulis - Ian Alexander, Ljerka Beus-Dukic.

Kisah tentang bagaimana para perintis kuda memerah susu

Perusahaan yang menjual asuransi memiliki situs web sendiri. Ini berfungsi dengan baik dan memiliki fungsi yang baik. Ini sudah memiliki logika bisnis yang kompleks.

Persyaratan pelanggan

Selain situs, Anda perlu membuat aplikasi seluler yang akan digunakan karyawan di ponsel mereka
Aplikasi harus memiliki mode offline.

Apa yang terjadi

Berdasarkan persyaratan, diputuskan untuk menulis dalam React Native. Pengembangan telah dimulai. Selama panggilan pertama, penyempurnaan dan penambahan persyaratan diterima:

Perusahaan mengeluarkan telepon kepada karyawan, dan semuanya bekerja di Android.
Pelanggan hanya tertarik pada mode offline.
Batas waktu - dua bulan.

Jelas, tugas memilah produk pihak ketiga yang sudah jadi dengan logika bisnis yang kompleks dan menulis yang baru dalam dua bulan tidak sesuai dengan kerangka waktu seperti itu. Diputuskan untuk menggunakan PWA (Aplikasi Web Progresif).

Saya sudah memiliki pengalaman dengan pekerjaan seperti itu. Bukan hanya aplikasi PWA yang ditulis, itu isomorfik. Layanan dari server pada klien digunakan kembali, pembungkus khusus ditulis dengan mana Anda dapat berkomunikasi dengan layanan ini. Sebuah router ditulis yang mengalihkan semua permintaan ke database MongoDB, pada klien, melalui adaptor, mereka bekerja dengan IndexedDB. Skema di bawah ini.

Jadi, masalahnya dengan persyaratan, yang tidak begitu sederhana. Pertimbangkan contoh apa saja persyaratannya:

Ada formulir, dan kami perlu membuat kesalahan validasi, jika URL yang salah dimasukkan, kami perlu menampilkan halaman 404. Apa yang salah dengan persyaratan? Mereka berbicara tentang apa yang harus dilakukan sistem. Tetapi untuk arsitek, sistem apa yang harus lebih penting. Jika Anda mempelajari apa yang harus dilakukan sistem, Anda bisa masuk terlalu dalam ke detail dan salah jalan. Persyaratan seperti itu disebut fungsional, mereka juga disebut persyaratan MoSCoW. Kata-kata yang sering ditemukan dalam persyaratan ini:

Semua persyaratan yang mengandung kata-kata ini tidak menarik bagi Anda. Jika Anda fokus pada persyaratan seperti itu, maka sistem monolitik akan dibangun tanpa arsitektur khusus sama sekali.

Kesimpulan

Arsitek harus fokus pada persyaratan non-fungsional, khususnya pada batasan dan atribut kualitas. Kata selanjutnya tentang ini.

Kisah gagak putih

Persyaratan pelanggan

Kembangkan layanan terpisah yang mengonversi dan menyimpan data dalam format xml.
Dia harus melakukan ini dari sistem warisan pihak ketiga.

Apa yang terjadi?

Kami mengembangkan layanan kerja yang baik, melakukannya di Node.js. Ini adalah bagaimana sistem secara keseluruhan mulai terlihat secara skematis bersama dengan layanan baru yang diperkenalkan.

Jelas, Node.js adalah domba hitam di sini, terlepas dari kenyataan bahwa semuanya bekerja dengan baik.

Kesalahan ditemukan saat transfer layanan ke pelanggan yang tidak terbiasa dengan Node.js. Situasi ini dengan sempurna menunjukkan peran mengidentifikasi kendala untuk proyek. Apa batasannya?

Teknis
Waktu dan anggaran
Stack Pengembang Pelanggan

Kesimpulan

Arsitek berkewajiban untuk mengetahui semua batasan yang ada yang dapat mempengaruhi produk akhir. Keterbatasan adalah keputusan arsitektur yang telah dibuat sebelum dan untuk Anda.

Selanjutnya, kita beralih ke atribut kualitas, kami memiliki minat khusus pada mereka.

Atribut kualitas

Perpustakaan yang sangat aman

Ada banyak atribut berkualitas, Anda hanya perlu melihat daftar yang diberikan Wikipedia kepada kami.

Kisah ini didasarkan pada atribut "keamanan". Ketika Anda mengunjungi perpustakaan, Anda hampir tidak berharap, menggunakan komputer di sana, bahwa Anda harus melalui otorisasi dua faktor dengan memasukkan email, telepon, dan kode verifikasi dari telepon. Namun demikian, ini terjadi. Kita melihat bahwa penerapan atribut kualitas secara buta juga dapat dilakukan.

Telepon di hutan

Bagaimana dengan kinerja? Jelas bahwa tidak ada orang yang tidak peduli dengan kinerja. Ini skripnya. Misalkan seseorang ingin menggunakan aplikasi seluler dari teleponnya ketika berada di hutan. Jadi, itu mempengaruhi sistem kami, tetapi tidak keseluruhan, tetapi antarmuka web. Misalnya, dia perlu mendapatkan beberapa data dalam waktu tiga detik. Ini adalah skenario kinerja yang harus kita dapatkan.

Ini adalah kasus penggunaan yang harus dikumpulkan oleh arsitek untuk membangun sistem berkualitas tinggi pada output. Ketika kami memiliki daftar persyaratan bisnis, atribut kualitas, kendala, kami mengenali semua pemangku kepentingan, kami mulai mengatasinya dalam diagram bagan. Mengatasi atribut-atribut pada diagram disebut taktik arsitektur. Taktik arsitektur apa yang dapat diterapkan pada sistem telepon di hutan berdasarkan skenario yang ada?

Tingkatkan UX sehingga tampaknya bagi seseorang produktivitasnya lebih tinggi.
Mengoptimalkan sumber daya (JS, CSS, gambar, font, dll.).
Lakukan caching.
Tambahkan pekerja layanan, jalur kritis.
Lakukan kompresi.
HTTP / 2.

Namun, dalam kasus telepon di hutan, UX dan jalur kritis tidak langsung cocok untuk kita. Dan sekali lagi, taktik harus ditentukan oleh skrip. Ini adalah karya arsitek, untuk memilih dari semua taktik yang diperlukan dalam kasus tertentu. Tapi aplikasi bukan hanya sebuah frontend. Kinerja juga dipengaruhi oleh DNS, backend, database, dan semua ini juga dapat dioptimalkan. Ada banyak taktik tentang cara melakukan ini, tetapi, sekali lagi, penerapan satu atau lain tergantung pada skenario penggunaan.

Mari kita coba menggunakan pola CQRS (segregation command query responsibility). Menggunakan pola ini sebagai taktik bahkan mempengaruhi beberapa lapisan aplikasi: baik back-end dan front-end.

Katakanlah ada database warisan yang sangat lambat, kami mengirim permintaan di sana dan setelah sepuluh detik kami mendapat respons. Selain itu, ini direplikasi dan Anda perlu membuat entri di kedua salinan. Kami di hutan dengan telepon ingin cepat membaca data kami dari database ini. Pola tersebut mengatakan bahwa kita harus memisahkan permintaan baca dan tulis. Tambahkan basis data baca cepat. Kami menambahkan semua cara untuk menyinkronkan database ini dengan yang sudah ada.

Penggunaan jenis taktik rumit ini harus ditentukan dengan sangat jelas oleh persyaratan.

Jadi, kami menggunakan beberapa taktik. Kami meluncurkan aplikasi dan melihat bahwa itu tidak membantu, karena tidak ada koneksi internet. Jadi kami sampai pada toleransi kesalahan yang harus dijaga oleh arsitek solusi.

Prajurit Timah yang Kuat

Tidak ada yang ingin aplikasi jatuh secara stabil beberapa kali sehari, semua orang menginginkan toleransi kesalahan.

Agar aplikasi dapat bekerja secara stabil, prinsip gagal cepat dapat diterapkan:

Selalu verifikasi poin integrasi terlebih dahulu.
Hindari koneksi yang lambat.
Periksa entri Anda.

Mengapa menggunakan ini, mari kita lihat contoh Lie Connection. Ini adalah koneksi yang mungkin ping sesuatu, tetapi pada kenyataannya tidak berfungsi. Ini dapat terjadi antara klien dan server, database dan server, antara layanan. Terapkan pola Pemutus Sirkuit ke sana.

Sementara semuanya berjalan dengan baik, kami tidak melakukan apa-apa. Segera setelah batas waktu terlampaui, kami menjadi offline dan setelah beberapa saat kami membuat permintaan baru. Jika permintaan lagi terjadi dengan kesalahan, sekali lagi kami tetap dalam mode offline dengan batas waktu meningkat. Dan jika permintaan berjalan dengan baik, kami kembali ke mode online. Dengan demikian, pola ini memungkinkan titik integrasi untuk diverifikasi dan koneksi lambat harus dihindari.

Kapal selam

Ada banyak pendekatan untuk memberikan toleransi kesalahan. Salah satunya adalah sekat (sekat, misalnya dalam kapal selam). Artinya adalah bahwa aplikasi tersebut ditulis sedemikian rupa sehingga terus bekerja, bahkan ketika kesalahan telah muncul di salah satu komponennya.

Kami memiliki logika bisnis tempat kami mengirim data dan menerima tanggapan. Kami mulai membingkainya dengan taktik kami, menambahkan validasi, skala. Terjadi kesalahan dalam logika bisnis. Kami mencatatnya. Sebagai informasi kesalahan, kita memerlukan konteks di mana itu terjadi. Masalahnya adalah bahwa dengan kerangka logika seperti itu, konteksnya tidak mungkin bertahan, oleh karena itu, kita perlu membuat memori dump. Memori dump adalah hal yang cukup produktif, dan kesalahan JavaScript jarang terjadi, oleh karena itu, ini adalah strategi yang cukup mahal untuk sumber daya komputasi. Kita perlu membagi kesalahan menjadi kritis dan tidak, dan membuangnya hanya untuk yang pertama.

Ember bocor

Strategi yang mirip dengan yang dijelaskan di atas digunakan dalam pola Leaky Bucket.

Kami memiliki penghitung untuk berbagai jenis kesalahan. Ketika kesalahan terjadi, penghitung kesalahan jenis ini bertambah. Pada batas waktu, penghitung ini berkurang. Tetapi jika jumlah kesalahan mulai keluar dari skala, penghitung tidak punya waktu untuk mengurangi dan, secara kiasan, meluap ember, setelah itu kita membuat memori dump. Selanjutnya, kami mengerjakan kesalahan yang menyebabkan penghitung meluap.

Harap dicatat bahwa layanan yang menerapkan pola ini juga akan dibungkus dengan taktik, validasi dan akan diskalakan. Jadi arsitektur dibangun.

Apa arti panah hijau? Layanan yang berbeda berinteraksi satu sama lain melalui berbagai protokol, database, dan layanan lainnya.

Bagi mereka yang ingin mempelajari lebih lanjut tentang pola toleransi kesalahan, buku Pola untuk perangkat lunak toleran kesalahan oleh Robert S. Hanmer akan sangat membantu.

Kami juga merekomendasikan buku "Arsitektur Perangkat Lunak dalam Praktek" oleh Len Bass, Paul Clements, Rick Kazman. Di dalamnya, Anda akan belajar tentang atribut kualitas dan taktik lain untuk mengikutinya.

Contoh makanan penutup

Kasing

Kami ingin menawarkan peningkatan pelanggan yang ada untuk platform saat ini.
Sekitar 400 situs statis telah ditulis di platform ini.
Masalahnya adalah itu mahal dan panjang.
Manajemen konten juga mahal dan panjang.
Platform ditulis dalam Drupal.

Misalkan Anda dapat menggunakan kerangka kerja berikut untuk menyelesaikan masalah ini:

Kami telah menemukan pihak yang berkepentingan. Perlu mendefinisikan tujuan.

Tujuan paling global adalah untuk memuaskan pelanggan.

Tujuan bisnis adalah untuk mengoptimalkan biaya pelanggan (ini sudah merupakan tujuan yang menarik bagi pelanggan).
Berikut ini adalah tujuan yang lebih pribadi: untuk mengurangi waktu yang diperlukan untuk membawa produk ke pasar, untuk mengurangi waktu manajemen konten.

Kemudian batasan berikut ditemukan:

Anda perlu menulis di Drupal, karena pelanggan telah membeli lisensi dan dukungan untuk beberapa waktu.
Proyek ini menggunakan ReactJS dan VueJS, dan pelanggan menginginkannya untuk terus, perusahaan tidak siap untuk mempertimbangkan kerangka kerja lain.

Setelah menetapkan atribut kualitas, kami menemukan:

Penting untuk meninggalkan kemampuan untuk mendukung semua 400 situs (rawatan).
, (testability).
(re-usability).
(performance).
(accessibility).

Ketika kita membangun arsitektur, kita perlu mengikuti model tertentu. Pertimbangkan model C4. Beberapa diagram dibangun.

Diagram konteks:

Tentukan peran orang yang akan bekerja dengan platform. Dalam contoh ini, ini adalah pengunjung, pengembang, dan pengelola konten.

Kami beralih ke diagram wadah:

Berdasarkan konteks bisnis, ada situs web yang dikunjungi pengguna. Pengembang bekerja dengan generator situs, manajer konten bekerja di hub konten. Kami melakukan integrasi dengan sistem pihak ketiga dalam proses memperbarui platform.

Diagram komponen terlihat seperti ini:

Kami melihat bahwa pengembang membuat tema dan komponen, Layanan Template juga berfungsi untuk mereka, yang mengagregasi perkembangan ini. Ada titik integrasi antara hub konten dan generator situs. Ada juga layanan template yang mengambil tema, komponen dan menghubungkannya ke data yang dikirimkan dari hub konten.

Bagaimana cara mempercepat alur kerja manajemen konten? Penting untuk memberikan kesempatan bagi manajer konten untuk bekerja secara langsung dengan modul pembuatan situs. Mengingat semua praktik sebelumnya, kami menambahkan pendekatan yang diperlukan ke modul Layanan Templat. Perhatikan bahwa Drupal digunakan sepenuhnya di hub konten. Kami menyimpulkan bahwa untuk generasi statis, kerangka kerja NuxtJS atau Next.js, yang masing-masing ditulis dalam Vue.js dan React.js, sesuai. Sebagai pengganti poin integrasi, sebaiknya gunakan GitHub dan cabang, jadi kami sampai pada pendekatan JAM. Didekripsi sebagai JavaScript, API, Markdown.

Dapat dilihat bahwa tumpukan yang diputuskan untuk digunakan berbeda dari aslinya. Di satu sisi, kami menggunakan Node.js dan semacam kerangka kerja modern. Kami akan meninggalkan Drupal untuk manajemen konten, tetapi dengan mengaturnya dari sistem kami, kami akan dapat berintegrasi dengan CMS baru di masa mendatang, yang mungkin lebih nyaman dan lebih cepat. Maka datanglah untuk memahami pendekatan Javascript, API, Markdown.

Kesimpulan

Anda perlu memilih tumpukan teknologi akhir dengan cermat. Inilah yang kami tulis dalam buku arsitek kami.

Cerita terakhir

Arsitek Kasus mengidentifikasi semua pemangku kepentingan, persyaratan, sasaran, batasan. Kemudian proyek tertentu dibuat. Pengembangan aplikasi itu normal, tetapi pada akhirnya proyek gagal.

Mengapa ini terjadi?

Faktanya adalah bahwa pengembang proyek tidak mengetahui persyaratan, pemangku kepentingan, keterbatasan dan atribut kualitas. Pengembangan dilakukan secara eksklusif dalam bentuk tugas di pelacak tugas, yang akhirnya menyebabkan runtuhnya seluruh proyek.

Kesimpulan

Arsitek harus mendampingi pengembangan proyek pada tahap awal untuk memastikan bahwa pengembangan dilakukan sesuai dengan arsitektur yang dirancang olehnya.

Ringkasan

Untuk meringkas, kami akan menulis daftar hal-hal penting untuk arsitektur. Cetak dan gantung di tempat yang mencolok. Sehingga kapal yang Anda bangun tetap di atas air, dan bahkan lebih baik berlayar ke arah yang benar:

Arsitektur apa pun dimulai dengan identifikasi pemangku kepentingan.
Anda perlu mempertimbangkan tujuan bisnis ketika merancang arsitektur.
Arsitek harus fokus pada persyaratan non-fungsional, khususnya pada batasan dan atribut kualitas. Dia harus mengerti aplikasi apa yang dia rancang seharusnya.
Taktik arsitektur harus ditentukan oleh skenario penggunaan.
Anda harus hati-hati memilih tumpukan teknologi akhir.
Diperlukan untuk menyertai pengembangan proyek pada tahap awal, sehingga dilakukan sesuai dengan arsitektur yang dirancang.

Jika Anda menyukai laporan ini, perhatikan: pada 24-25 November, HolyJS baru akan diadakan di Moskow , dan juga akan ada banyak hal menarik di sana. Informasi yang sudah diketahui tentang program ini ada di situs, dan tiket dapat dibeli di sana.

Pengembangan arsitektur proyek, kapal dan JavaScript