Dalam artikel ini, saya akan memberi tahu Anda, menggunakan evolusi proyek saya sebagai contoh, sejarah transisi dan visi pemrograman kontrak.
Pada awalnya saya ingin menamai artikel - "Kontrak pemrograman", sejauh pendekatan yang digunakan adalah untuk membagi semua logika bisnis menjadi kontrak data dan layanan klien menggunakan kontrak ini dan berinteraksi satu sama lain melalui struktur data ini, sehingga sama Struktur berhasil diproses di berbagai layanan.
Sesuatu yang akan saya jelaskan dalam bahasa saya sendiri.
Kisah transisi saya ke pemrograman kontrak dimulai dengan fakta bahwa saya memiliki proyek warisan yang terlalu banyak dengan sejumlah besar fungsi berbeda dalam area bisnis yang sama. Plus, semua ini masih multithreading dan kustomisasi untuk klien yang berbeda. Secara khusus, area bisnis adalah pertukaran dokumen elektronik yang relevan secara hukum antara sistem akuntansi, file, dan layanan cloud.
Dalam proses pengembangan sistem, persyaratan bisnis baru muncul dan sebagai hasilnya, proyek dengan cepat berkembang dan diperumit oleh fungsionalitas baru, yang pada beberapa tahap menyebabkan situasi di mana arsitektur proyek mulai menyerupai beberapa aplikasi terpisah dengan fungsi terkait. Hanya fungsi ini diimplementasikan, bukan dari elemen umum, tetapi dari struktur yang serupa tetapi diimplementasikan secara berbeda di majelis dan ruang nama yang berbeda.
Secara visual, arsitektur seperti itu dapat direpresentasikan sebagai beberapa fungsi vertikal
Ciri khas dari arsitektur semacam itu adalah bahwa jika ada persyaratan atau kesalahan tambahan yang muncul, maka diperlukan untuk melaksanakan tugas tersebut di semua "modul fungsional" sistem, dan tidak di satu area. Fitur karakteristik lainnya adalah kehadiran dalam proyek sejumlah besar pembangun, yang mengarah pada pembagian vertikal area bisnis. Pengembang menerapkan algoritma baru untuk persyaratan bisnis baru dalam kode pembangun, yang mengarah pada munculnya entitas baru dengan struktur berbeda untuk objek bisnis yang sama. Diakui, pendekatan ini dapat dianggap lebih berorientasi objek daripada pendekatan kode-belakang sederhana dengan kode spaghetti. Dengan demikian, jika Anda melihat sejumlah besar pembangun di proyek Anda, maka transisi ke pendekatan kontak akan menyederhanakan dukungan dan mempercepat pengembangan proyek Anda.
Suatu ketika, di perusahaan, kami dihadapkan dengan fakta bahwa klien yang kami laksanakan mulai menyatakan bahwa sistem yang saya kembangkan sering menghasilkan kesalahan. Saya tidak bisa berdebat dengan ini, meskipun kesalahan muncul secara berkala, tetapi mereka diperbaiki dan beberapa klien menginstal sistem dan menggunakannya. Saya harus mengucapkan terima kasih bahwa klien itu berbahaya dan pemilih, dan sangat hati-hati menguji sistem kami selama periode implementasi.
Saya sendiri juga tidak menyukai kenyataan bahwa saya tidak punya cukup waktu untuk pengembangan dan dukungan, meskipun banyak upaya, dan pada titik tertentu saya tidak tahu apa lagi yang bisa memperbaiki sistem dan membuatnya lebih stabil.
Keputusan itu tiba-tiba dan tidak terduga.
Saya mengerti betul bahwa objek bisnis yang sama diimplementasikan secara berbeda dalam modul sistem yang berbeda - dokumen dari berbagai jenis, kwitansi, pekerja, klien layanan, klien basis data, klien file dengan kemampuan untuk menyimpan dokumen dalam berbagai format (penyesuaian untuk klien yang berbeda;) )
Bagian dari logika diimplementasikan dalam entitas, yang mencegah penggunaan entitas yang sama dalam algoritma yang berbeda.
Lalu saya memutuskan - perlu untuk membuat sesuatu seperti konstruktor tunggal dengan rincian dari mana semua algoritma yang diimplementasikan dalam sistem dapat dirakit. Yang logis, karena mengurangi jumlah kelas yang serupa, dan menyederhanakan dukungan.
Saya memutuskan untuk secara ketat membagi "alam semesta" aplikasi saya menjadi
- kontrak data - struktur data yang berisi dan hanya digunakan untuk penyimpanan data
Documents
Amplop
Tanda terima
EP
...
- klien-layanan - Saya secara khusus menulis bahwa klien adalah layanan, karena ketika menerapkan setiap sistem yang berinteraksi di area bisnis, saya menyatakannya sebagai amplop pada sistem ini, di mana metode untuk bekerja dengan kontrak tanggal diimplementasikan. Dan selain fakta bahwa kelas-kelas ini adalah pembungkus layanan, mereka juga mengandung logika mengikat yang diperlukan, konversi dan transformasi untuk menyederhanakan logika bisnis
Selain itu, penebang menempel pada klien ini. Itu memungkinkan Anda untuk dengan cepat menemukan titik kesalahan oleh log. (di masa depan, banyak panggilan menghilang ketika, oleh log, pengguna sendiri mulai memahami di mana mereka memiliki kesalahan - sistem file, jaringan, sistem akuntansi atau layanan web operator)
Sebagai contoh
CloudClient - klien layanan cloud tempat dokumen dikirim dan diproses
- Unduh
- kirim
- Dapatkan
- Unduh
- Setuju
...
FileSystemClient - klien sistem file
ERPClient - sistem akuntansi klien
Klien menerapkan semua metode yang sebelumnya digunakan dalam algoritma di semua modul, yang memungkinkan untuk dengan cepat dan mudah mengimplementasikan algoritma yang baru diimplementasikan dari bagian yang sama.
Dan alokasi metode fungsi serupa di masing-masing klien menyebabkan spesialisasi yang lebih besar dan penggunaan kembali kode.
Arsitektur sekarang menjadi diagram seperti pada gambar
Saya mengalokasikan semua objek dasar dari desainer saya untuk perakitan dengan akhir SDK (Software Developers Kit) dan menjadi lebih mudah untuk bekerja dan yang paling penting lebih menyenangkan. Pekerjaan sudah tidak lagi menjadi pembuatan kruk dan solusi sementara, dan sekarang sikap terhadap proyek dari dalam menjadi lebih serius dari kenyataan bahwa sekarang saya melihat banyak sekali skalabilitas dan arsitektur kompetitif. Ini karena fakta semacam itu secara signifikan meningkatkan motivasi dan membuka cakrawala profesional baru.
Berdasarkan SDK yang dibuat, saya menyerahkan untuk menerapkan lapisan logika bisnis yang mengotomatiskan pelaksanaan tugas bisnis langsung. Karena semua nuansa teknis dibawa ke lapisan bawah yang terletak di klien, penerapan algoritma yang sama disederhanakan dan mulai terlihat jauh lebih menyenangkan.
Pendekatannya sederhana, dan memungkinkan untuk menyederhanakan pengembangan lebih lanjut dan yang sangat penting adalah meningkatkan fleksibilitas arsitektur. Ya, ini akan membutuhkan refactoring yang luas. Dalam kasus saya, butuh 2 minggu pengembangan dalam mode fanatik. Tetapi setelah itu, saya hampir tidak kode, karena semuanya bekerja dengan stabil.
Dan berkat pemisahan tanggung jawab (SPR), dan log, saya dapat dengan cepat menekan kesalahan layanan pihak ketiga, melibatkan kesalahan di pihak saya. Sebelumnya, ini membutuhkan analitik yang memakan waktu cukup lama.
Pendekatan ini baik untuk digunakan pada lapisan tertentu. Pada lapisan aplikasi yang lebih tinggi, model anemia mungkin lebih nyaman, hanya saja lebih baik menerapkan model anemia berdasarkan pendekatan kontrak.