👩🏾‍🏭 😻 🤙🏻 Layanan microser atau sistem modular? Bagaimana pelanggan dapat memilih pendekatan arsitektur TI suatu produk ✊🏿 🤲🏻 ☺️

Microservice dan sistem modular adalah jenis arsitektur solusi TI.

Saat bekerja dengan modul, kami menyelesaikan versi kotak dari produk TI yang ada.

Yang kami maksud dengan versi kotak adalah monolith, sistem siap pakai dengan inti yang dikirimkan ke semua pelanggan dengan cara yang sama, "sebagaimana adanya."

Penyempurnaan terdiri dalam membuat modul dengan fungsi yang hilang.

Kami mendapatkan modul baru dengan menggunakan kembali bagian monolith (inti atau modul lainnya).
Logika bisnis tertulis di dalam monolith: untuk program (aplikasi, situs, portal) ada satu titik masuk dan satu titik keluar.

Ketika bekerja dengan layanan microser, kami membuat produk IT dari awal, menyusunnya dari "batu bata" - layanan microser atom yang bertanggung jawab atas proses kecil yang terpisah (mengirim surat, menerima informasi pesanan, mengubah status pesanan, membuat klien, dll.).
Serangkaian blok tersebut digabungkan dengan logika bisnis ke dalam sistem umum (misalnya, menggunakan BPMS). Meskipun terdapat koneksi, setiap blok bersifat otonom dan memiliki titik masuk dan keluar sendiri.

Sebagian besar produk TI untuk pelanggan kami dimulai dengan pengembangan modular. Beberapa dari mereka berkembang dari waktu ke waktu ke layanan microser. Untuk bagian lain, layanan microser tidak diperlukan. Dalam artikel ini, kita akan memeriksa mengapa ini benar-benar terjadi dan kriteria apa yang membantu menentukan apakah perlu untuk mengimplementasikan layanan-layanan mikro atau jika Anda harus tetap bekerja dengan modul-modul.

gambar

Manfaat Arsitektur Modular

Semua sistem CMS (Bitrix, Magento, Drupal, Hybris, dll.), CRM, ERP, WMS dan banyak lainnya memiliki versi kotak. Mereka menjual dengan baik dan dalam permintaan tinggi.
Mari kita lihat alasan obyektif mengapa pelanggan paling sering memilih untuk bekerja dengan arsitektur modular dan dengan sukarela membeli solusi kotak.

Implementasi kecepatan tinggi

Menginstal, mengonfigurasi, dan mengisi direktori untuk perangkat lunak semacam itu membutuhkan sedikit waktu. Adalah realistis bagi perusahaan menengah untuk mulai bekerja dengan sebuah kotak tiga hingga empat bulan setelah dimulainya, kadang-kadang bahkan sedikit lebih awal.

Untuk usaha kecil, periode ini bisa hanya beberapa hari.
. , enterprise- .
. . , , , .
,

. , .

Ada faktor subyektif lain yang dapat menyesatkan dan memengaruhi keputusan untuk menggunakan kotak dan modul.

1. Perlombaan produsen

Penjual perangkat lunak dengan hangat meyakinkan pelanggan bahwa solusi mereka di luar kotak adalah solusi yang tepat: telah diuji selama bertahun-tahun, dan modis, dan perusahaan, dan populer, dan pemasaran ... Setiap pemasok: Bitrix, Magento, SAP, Oracle, OpenCart, Django dan semua orang bekerja keras dalam teknik pemasaran dan penjualan.

2. Kesalahpahaman tentang kompleksitas peningkatan

Pelanggan sering kali penuh dengan optimisme. Mereka memilih perangkat lunak kotak dan berpikir: “Ya, perbaikan akan diperlukan. Tapi itu mudah: Anda tidak perlu menemukan sesuatu yang baru. Kami memiliki versi populer, tetapi jutaan pengguna tidak dapat membuat kesalahan dan membeli produk yang buruk. "
Dalam pandangan mereka, proses penyempurnaan terlihat seperti ini: ada fungsionalitas (kotak) utama. Untuk "menyelesaikan" sesuatu di dalamnya, pengembang harus "hanya" mendefinisikan kembali modul atau dengan cepat menulis sendiri. Dalam hal ini, tidak perlu menggunakan metode berulang, karena semuanya dianggap dipikirkan dalam monolit: metode umum untuk menghitung pajak ditentukan, ada aturan yang jelas untuk menulis metode pengiriman dan pembayaran, alur kerja pesanan yang jelas, dll.

Dalam kehidupan nyata, berbagai hal berbeda. Dan setelah emosi yang menyenangkan dari awal yang mudah bekerja dengan kotak, pelanggan masih dihadapkan dengan kenyataan pahit. Paling sering hal ini terjadi dengan perusahaan dari bisnis menengah dan besar, proyek-proyek yang memiliki logika bisnis yang unik, dan peningkatan skala besar diperlukan di dalamnya.

Jika perusahaan Anda adalah bisnis kecil dan perangkat lunak bukan aset utama Anda, maka kemungkinan besar, solusi kotak (atau lebih baik - cloud) yang populer akan cocok untuk Anda.

Mari kita lihat masalah apa yang mungkin Anda temui ketika bekerja dengan arsitektur modular dan bagaimana layanan Microsoft membantu untuk menghindari ini.

Masalah sistem modular

Masalah utama adalah bahwa semua sistem modular tidak dirancang untuk mendefinisikan ulang fungsionalitas secara serius. Mereka memiliki kotak, modul yang sudah jadi - yang lebih baik untuk menggunakannya.

Semakin dekat ke tingkat perusahaan ukuran proyek dan kompleksitas kustomisasi mereka, semakin banyak masalah dengan penyelesaian modul. Mari kita bicara tentang yang utama.

Masalah No. 1. Inti dari sistem menjadi titik perlambatan, dan modularitas menjadi komplikasi yang tidak perlu.

Katakanlah proyek Anda dikaitkan dengan logika gudang kompleks. Jika Anda memilih arsitektur modular, maka pengembang tidak hanya perlu membuat fungsionalitas untuk mengelola gudang ini - mereka perlu mendefinisikan ulang atau memperluas modul multicore, yang, pada gilirannya, menggunakan metode kernel.

Dalam hal ini, perlu untuk memperhitungkan logika pengembalian yang kompleks ke gudang: ketergantungan pada peristiwa dari sistem CRM, perpindahan barang antar katalog, dll. Juga perlu mempertimbangkan logika tersembunyi yang terkait dengan pengembalian dana, poin bonus, dll.

Ketika begitu banyak redefinisi terjadi, monolit berubah secara signifikan. Penting untuk diingat bahwa hubungan antara volume fungsional baru dan jumlah modul adalah non-linier: untuk menambah satu fungsi, Anda harus membuat perubahan pada beberapa modul, yang masing-masing mengubah operasi yang lain, atau mendefinisikan kembali sejumlah besar metode modul lain dalam modul baru, yang tidak mengubah esensi.

Setelah semua perubahan, sistem menjadi sangat rumit sehingga dibutuhkan sejumlah besar jam untuk menambahkan kustomisasi berikut.

gambar

Masalah No. 2. Prinsip dokumentasi-mandiri tidak didukung dalam sistem modular.

Dokumentasi untuk sistem modular sulit diperbarui. Sangat banyak, dan menjadi usang dengan setiap perubahan. Penyempurnaan satu modul memerlukan perubahan pada beberapa dokumen lain (dalam pengguna, dokumentasi teknis), dan semuanya perlu ditulis ulang.

Sebagai aturan, tidak ada orang yang melakukan pekerjaan seperti itu: menghabiskan waktu spesialis IT yang berharga untuk hal ini berarti hanya menghabiskan anggaran. Bahkan penggunaan penyimpanan dokumentasi dalam kode (PHPDoc) tidak menjamin keandalannya. Pada akhirnya, jika dokumentasi mungkin berbeda dari implementasinya, itu tentu akan berbeda.

Masalah No. 3. Koherensi kode yang lebih besar - jalan menuju kemunduran: "mereka mengubahnya di sini, terjatuh"

Masalah klasik sistem modular adalah dalam perjuangan melawan regresi.

Pengembangan TDD sulit digunakan untuk monolit karena koherensi metode yang berbeda (Anda dapat dengan mudah menghabiskan 30 baris tes pada lima baris kode, ditambah perlengkapan).
Oleh karena itu, dalam perang melawan regresi, perlu untuk menutupi fungsional dengan tes integrasi.
Namun mengingat perkembangan yang sudah lambat (setelah semua, Anda perlu mengembangkannya dengan hati-hati untuk menyediakan banyak penggantian), pelanggan tidak ingin membayar untuk tes integrasi yang kompleks.

Tes fungsional menjadi sebesar tidak berarti. Mereka berjalan berjam-jam, bahkan secara paralel.

Ya, front modern seperti PWA dapat diuji API secara fungsional. Tetapi tes sering bergantung pada penerimaan data dari sirkuit eksternal - dan karenanya mulai gagal jika, misalnya, uji SAP berada di belakang toko bahan makanan selama N bulan, dan uji "1C" mengirim data yang salah.

Ketika Anda harus mengunggah suntingan kecil untuk beberapa modul, pengembang harus memilih dari dua kejahatan: mulai menjalankan CI penuh dan menghabiskan banyak waktu pada penyebaran atau lay out hotfix tanpa menjalankan tes, berisiko melanggar sesuatu. Sangat dramatis ketika pengeditan tersebut tiba dari departemen pemasaran pada Black Friday. Tentu saja, cepat atau lambat, regresi dan kesalahan manusia akan terjadi. Apakah itu familier?

Pada akhirnya, untuk memenuhi tujuan bisnis, tim beralih ke mode operasi darurat, dengan terampil menyulap tes dan dengan hati-hati melihat dashboard dari log - Kibana, Grafana, Zabbix ... Dan apa yang kita dapatkan pada akhirnya? Habis terbakar.

Anda harus mengakui bahwa situasi dengan regresi tidak seperti "perusahaan stabil" sebagaimana mestinya dalam mimpi dan impian pelanggan.

Masalah # 4: Konektivitas Kode dan Pembaruan Platform

Masalah lain dengan konektivitas kode adalah kesulitan dalam memperbarui platform.

Misalnya, Magento berisi dua juta baris kode. Di mana pun kita melihat, ada banyak kode di mana-mana (Akeneo, Pimcore, Bitrix). Saat menambahkan fungsionalitas ke kernel, akan lebih baik untuk mempertimbangkan perubahan akun di modul khusus Anda.

Ini adalah contoh langsung untuk Magento.
Pada akhir 2018, versi baru platform Magento 2.3 dirilis. Multistores dan Elasticsearch telah ditambahkan ke Edisi Open Source. Selain itu, ribuan bug diperbaiki di kernel dan beberapa barang dalam OMS ditambahkan.

Apa yang dihadapi proyek e-Commerce yang telah menulis multistores di Magento 2.2? Mereka perlu menulis ulang banyak logika dalam pemrosesan order, checkout, kartu produk untuk menggunakan fungsionalitas kotak. Memang, “benar sekali” - mengapa menduplikasi fungsi versi kotak dalam modul? Mengurangi volume kode khusus dalam proyek besar selalu berguna - setelah semua, semua metode kotak memperhitungkan multi-gudang ini, dan memperbarui kotak tanpa refactoring tersebut bisa sia-sia (perhatikan masalah keamanan untuk kesederhanaan, terutama karena mereka dapat digulung tanpa memperbarui).

Sekarang bayangkan: berapa banyak waktu yang akan dihabiskan untuk pembaruan semacam itu dan bagaimana ini bisa diuji tanpa tes integrasi, yang sulit untuk ditulis?

Tidak mengherankan bahwa bagi banyak orang, memperbarui platform terjadi baik tanpa refactoring, tetapi dengan peningkatan duplikasi, atau (jika tim ingin melakukan segalanya dalam feng shui) dengan "meninggalkan" untuk waktu yang lama dalam refactoring dan memulihkan ketertiban.

Masalah No. 5. Opacity dari proses bisnis

Salah satu masalah paling penting dalam manajemen proyek adalah bahwa pelanggan tidak melihat semua logika dan semua proses bisnis proyek. Mereka hanya dapat dipulihkan dari kode atau dari dokumentasi (relevansinya, seperti yang kami katakan sebelumnya, bermasalah untuk dipelihara dalam sistem modular).

Ya, Bitrix memiliki bagian BPM, sementara Pimcore memiliki visualisasi alur kerja. Tetapi upaya ini untuk mengelola modul melalui proses bisnis selalu bertentangan dengan kehadiran kernel. Selain itu, peristiwa, penghitung waktu kompleks, operasi transaksional - semua ini tidak terjadi dalam BPM monolit. Saya ulangi: ini berlaku untuk perusahaan menengah dan besar. Untuk perusahaan kecil, kemampuan sistem modular sudah cukup. Tetapi jika kita berbicara tentang segmen perusahaan, maka solusi ini masih tidak memiliki pusat kendali tunggal di mana Anda dapat pergi dan melihat diagram dari setiap proses, status apa pun, bagaimana tepatnya sesuatu terjadi, apa saja pengecualian, penghitung waktu, peristiwa dan mahkota . Tidak ada cukup kesempatan untuk mengubah proses bisnis, tetapi tidak modul. Manajemen proses proyek tenggelam dalam kecepatan perubahan dan koherensi logika.

Masalah 6. Kompleksitas penskalaan sistem

Jika Anda menggunakan monolith, itu akan digunakan secara keseluruhan dengan semua modul di setiap server aplikasi. Itu Anda tidak dapat secara terpisah meningkatkan layanan pemrosesan pesanan dan bonus dalam satu musim, secara terpisah dari sisa kode.

Perlu lebih banyak memori dan prosesor, yang sangat meningkatkan biaya cluster.

Bagaimana layanan microser menyelamatkan pelanggan dari kekurangan khas pengembangan modular. Orkestra Layanan Mikro di Camunda dan jBPM

Spoiler: Solusi untuk masalah yang tercantum dalam paragraf terakhir dimungkinkan menggunakan BPMS dan mengatur sistem layanan mikro.

BPMS (sistem manajemen proses bisnis bahasa Inggris) adalah perangkat lunak untuk mengelola proses bisnis dalam suatu perusahaan. BPMS populer yang bekerja dengan kami adalah Camunda dan jBPM.

Orkestrasi menjelaskan bagaimana layanan harus berinteraksi satu sama lain menggunakan olahpesan, termasuk logika bisnis dan serangkaian tindakan. Menggunakan BPMS, kami tidak hanya menggambar skema abstrak - proses bisnis kami akan dieksekusi sesuai dengan yang ditarik. Apa yang kita lihat dalam diagram dijamin berkorelasi dengan cara proses bekerja, apa layanan-mikro yang digunakan, parameter apa, sesuai dengan tabel keputusan mana, logika tertentu dipilih.

Sebagai contoh, kami mengambil proses yang sering ditemui - mengirim pesanan untuk pengiriman.

Dengan pesan atau panggilan langsung apa pun, kami mulai memproses pesanan dengan proses memilih metode pengiriman. Logika pemilihan diatur.

Akibatnya, proses, layanan, dan pengembangan:

menjadi mudah dibaca;
self-documenting (mereka bekerja persis seperti yang digambar, dan tidak ada rassynchron antara dokumentasi dan pekerjaan kode yang sebenarnya);
cukup debugged (mudah untuk melihat bagaimana proses ini atau itu berjalan dan memahami apa kesalahannya).

Kami akan berkenalan dengan prinsip-prinsip dimana sistem manajemen proses bisnis bekerja.

Prinsip BPMS No. 1. Pembangunan Menjadi Visual dan Proses

BPMS memungkinkan Anda untuk membuat proses bisnis di mana tim proyek (pengembang atau pengguna bisnis) menentukan urutan peluncuran layanan-layanan mikro, serta kondisi dan cabang di mana ia bergerak. Dalam hal ini, satu proses bisnis (urutan tindakan) dapat dimasukkan dalam proses bisnis lain.

Semua ini disajikan dengan jelas di BPMS: secara real time Anda dapat menonton skema ini, mengeditnya, menempatkannya dengan cara yang produktif. Di sini, prinsip lingkungan yang mendokumentasikan diri terpenuhi secara maksimal - prosesnya bekerja persis seperti yang divisualisasikan.

Semua layanan microsoft menjadi kubus proses yang dapat ditambahkan dari snap ke pengguna bisnis. Bisnis mengelola prosesnya, dan pengembang bertanggung jawab atas ketersediaan dan operasi yang benar dari layanan mikro tertentu. Selain itu, semua pihak memahami logika umum dan tujuan dari proses tersebut.

Prinsip BPMS No. 2. Setiap layanan memiliki input dan output yang jelas.

Prinsipnya terdengar sangat sederhana, dan mungkin bagi pengembang atau pengguna bisnis yang tidak berpengalaman bahwa BPMS tidak meningkatkan strategi penulisan layanan mikro dengan cara apa pun. Seperti, layanan microser biasa dapat ditulis tanpa BPMS.

Ya, itu mungkin, tetapi sulit. Ketika seorang pengembang menulis layanan mikro tanpa BPMS, ia pasti memiliki keinginan untuk menghemat abstrak. Layanan microsoft menjadi terus terang besar, dan terkadang mereka bahkan mulai menggunakan kembali yang lain. Ada keinginan untuk menghemat transparansi transfer hasil dari satu layanan ke yang lain.

BPMS mendorong Anda untuk menulis lebih abstrak. Pengembangan dilakukan dengan tepat proses, dengan definisi input dan output.

Prinsip BPMS No. 3. Concurrency dari pemrosesan antrian

Bayangkan proses pemrosesan pesanan: kita harus pergi ke suatu pasar, mengambil semua pesanan yang baik dan mulai memprosesnya.

gambar

Lihatlah diagram (bagian dari diagram). Di sini ditentukan bahwa setiap 10 menit kami memeriksa semua pesanan pasar, kemudian berjalan secara paralel (seperti yang ditunjukkan oleh "hamburger" vertikal dalam Pesanan Proses) pemrosesan setiap pesanan. Jika berhasil, transfer semua data ke ERP dan selesaikan pemrosesan.

Jika kita tiba-tiba perlu menaikkan log untuk memproses pesanan tertentu, di Camunda, JBoss atau BPMS lainnya, kita akan dapat sepenuhnya memulihkan semua data dan melihat di mana antrian itu dan dengan parameter input / output apa.

Prinsip BPMS No. 4. Kesalahan dan eskalasi

Bayangkan bahwa suatu kesalahan terjadi selama proses pengiriman. Misalnya (omong-omong, ini kasus nyata), perusahaan transportasi menerima pesanan, dan kemudian gudang dibakar. Kisah nyata lainnya: terburu-buru Malam Tahun Baru, produk pertama kali ditunda, dan kemudian, mungkin, hilang.

Dalam hal ini, peristiwa dipicu oleh mouse di BPMS, misalnya, pemberitahuan klien jika waktu pengiriman telah lewat. Jika Anda menerima kesalahan dari perusahaan transportasi di dalam, Anda dapat memulai proses di cabang Anda sendiri dan mengganggu semuanya: beri tahu, berikan diskon pada pesanan berikutnya, kembalikan uangnya.

Semua pengecualian semacam itu sulit tidak hanya untuk program di luar BPMS (misalnya, penghitung waktu dalam penghitung waktu), tetapi juga harus dipahami dalam konteks keseluruhan proses.

Prinsip BPMS No. 5. Pilihan tindakan untuk salah satu acara dan opsi antarproses

Kirim pesanan yang sama dalam pengiriman.

Secara total, kami memiliki tiga skenario:

barang dikirim seperti yang diharapkan;
barang tidak dikirim seperti yang diharapkan;
barang telah hilang.

Langsung di BPMS, kita dapat menentukan prosedur pengiriman barang ke perusahaan transportasi dan mengharapkan salah satu peristiwa dengan memesan:

pengiriman yang berhasil (pesan dari proses pengiriman produk bahwa semuanya dikirimkan);
atau timbulnya beberapa waktu.

Jika waktu belum berlalu, Anda perlu memulai layanan lain: parsing pesanan khusus ini dengan operator (Anda perlu mengatur tugas untuk itu dalam sistem OMS / CRM untuk mengetahui di mana pesanan berada) dengan pemberitahuan lebih lanjut dari klien.

Tetapi jika selama investigasi pesanan telah disampaikan, Anda harus menghentikan investigasi dan menyelesaikan pesanan.

Di BPMS, semua interupsi dan pengecualian ada di pihak BPMS. Anda tidak membebani kode dengan logika ini (dan keberadaan logika tersebut dalam kode akan membuat layanan microser besar dan buruk digunakan kembali dalam proses lain).

Prinsip BPMS No. 6. Di Camunda Anda, Anda akan melihat semua log

Menggunakan acara dan opsi antarproses, Anda:

Anda melihat seluruh rangkaian peristiwa dalam satu jendela (apa yang terjadi dengan urutan, cabang pengecualian yang dilaluinya, dll. - mudah dilihat);
Anda dapat mengumpulkan semua analitik untuk BI berdasarkan log BPMS saja (tanpa perlu membebani layanan Microsoft dengan peristiwa logging).

Akibatnya, Anda akan dapat mengumpulkan statistik secara khusus tentang masalah pemrosesan, tingkat transisi, semua proses perusahaan. Ada penyatuan informasi logging - mudah untuk menghubungkan acara dalam pengiriman dengan tindakan operator atau acara dari sistem informasi lainnya.

Perhatikan perbedaan dengan sistem modular: log universal juga dapat dibuat di sana, tetapi ketika berinteraksi dengan sistem lain, Anda perlu melakukan sesuatu dengan penyatuan pencatatan di dalamnya, dan ini tidak selalu memungkinkan.

Kesimpulan: perbandingan arsitektur perangkat mikro dan modular

Setiap jenis arsitektur memiliki kelebihan dan kekurangan. Tidak ada solusi universal.

Kami tidak menganjurkan pergeseran besar-besaran ke layanan mikro. Sebaliknya, untuk bisnis kecil atau ketika menggunakan sedikit penyesuaian, pendekatan modular akan lebih cocok.

Juga, kami tidak menentang solusi TI apa pun (Bitrix, Magento, kerangka kerja seperti Symfony atau Django, dll.), Karena kami mengembangkan lebih dari enam ribu jam kode setiap bulan pada kerangka kerja ini saja, dan jumlah front'a dan layanan microser. Oleh karena itu, kami yakin bahwa penting untuk mencari solusi teknis yang sesuai, dan tidak mempromosikan penggunaan platform tertentu (yang, sayangnya, bagian penting dari penjualan di bidang TI sedang meluncur).

Di bagian artikel sebelumnya, Anda belajar tentang kerugian dan kelebihan arsitektur modular. Kami berharap ini sudah membantu mengevaluasi apakah penyempurnaan versi kotak atau pembuatan layanan microser dari awal akan lebih cocok. Jika tidak mungkin untuk memutuskan, mari kita lihat bagaimana berbagai jenis arsitektur berubah tergantung pada kehidupan proyek.

Pada awal proyek:

dengan microservices - Anda tidak memiliki fungsionalitas, dan Anda harus menulis semuanya untuk mulai bekerja;
dengan sistem modular - dari versi kotak, sejumlah besar fungsi segera tersedia untuk Anda, dan Anda dapat mulai menggunakan produk segera setelah pembelian.

Setelah 3-4 bulan pertama pengembangan (ini adalah tanggal rilis rata-rata untuk MVP pertama) dan seterusnya:

dengan microservices - volume fungsionalitas secara bertahap disejajarkan dengan versi kotak. Untuk bisnis menengah, arsitektur microservice akan mengejar ketinggalan dengan modular cukup cepat, tetapi untuk besar - umumnya secara instan. Dan di masa depan, pemeliharaan dan pengembangan sistem modular dalam hal unit fungsional akan meningkat;
dengan sistem modular - kecepatan pengembangan fungsionalitas akan jauh lebih rendah daripada di layanan mikro.

Sebagai kesimpulan, mari kita lihat bagaimana orkestrasi layanan microser terlihat dengan contoh spesifik.

Contoh layanan visualisasi orkestrasi

Pertimbangkan orkestrasi layanan menggunakan Camunda. Dari gambar-gambar berikut, Anda dapat mengevaluasi betapa mudahnya mengelola layanan microser menggunakan BPMS dengan orkestrator. Semua proses adalah visual, logikanya jelas.

Proses bisnis terlihat seperti ini:
gambar

Contoh (pesanan, ketersediaan layanan):

gambar

Dapat dilihat bahwa dalam pesanan ini ada cabang "Tidak ada barang".

Salinan lain dari pesanan (pergi ke perakitan):

gambar

Pesanan lebih jauh dan sesuai dengan tabel keputusan (DMN) pergi ke cabang pemrosesan oleh operator layanan pengiriman tertentu (Boxberry):

gambar

Perawatan untuk proses bersarang: Proses

gambar

bersarang bekerja:

gambar

Sejarah proses bisnis:

gambar

Properti visualisasi ini:

proses bisnis mudah dibaca bahkan oleh pengguna yang tidak siap;
mereka dapat dieksekusi, yaitu, mereka bekerja persis seperti yang digambar, tidak ada rassynchron antara "dokumentasi" dan kerja aktual dari kode;
prosesnya transparan: mudah untuk melihat bagaimana impor, pesanan, pemrosesan berjalan, mudah untuk melihat di mana kesalahan itu dibuat.

Ingatlah bahwa kami di kt.team menggunakan pengembangan modular dan microservice, memilih opsi yang tepat untuk setiap produk secara individual. Tetapi jika pilihan telah dibuat dalam mendukung arsitektur layanan-mikro, maka kami sangat yakin bahwa tidak mungkin dilakukan tanpa sistem BPM seperti Camunda atau jBPM.

Lihat juga: video pada topik "Arsitektur microservice atau monolitik: apa yang harus dipilih?"

Layanan microser atau sistem modular? Bagaimana pelanggan dapat memilih pendekatan arsitektur TI suatu produk