REL03-BP02 Bangun layanan yang berfokus pada domain dan fungsionalitas bisnis khusus
Arsitektur berorientasi layanan (SOA) menetapkan layanan dengan fungsi yang digambarkan dengan baik berdasarkan kebutuhan bisnis. Layanan mikro menggunakan model domain dan konteks yang dibatasi untuk menarik batas-batas layanan di sepanjang batas konteks bisnis. Berfokus pada domain dan fungsionalitas bisnis dapat membantu tim untuk menentukan persyaratan keandalan sendiri untuk layanan mereka. Konteks yang dibatasi mengisolasi dan memisahkan logika bisnis, sehingga memungkinkan tim memiliki penalaran yang lebih baik tentang bagaimana menangani kegagalan.
Hasil yang diinginkan: Rekayasawan dan pemangku kepentingan bisnis bersama-sama menetapkan konteks yang dibatasi dan menggunakannya untuk merancang sistem sebagai layanan yang memenuhi fungsi bisnis tertentu. Tim-tim ini menggunakan praktik yang telah lazim seperti event storming untuk menentukan persyaratan. Aplikasi baru dirancang sebagai batas layanan yang ditetapkan dengan baik dan penggabungan longgar. Monolit yang ada diurai menjadi konteks-konteks yang dibatasi
Layanan berorientasi domain dijalankan sebagai satu atau beberapa proses yang statusnya tidak sama. Layanan-layanan tersebut secara independen merespons fluktuasi permintaan dan menangani skenario kesalahan dengan berpatokan pada persyaratan khusus domain.
Antipola umum:
-
Tim dibentuk berdasarkan domain-domain teknis tertentu seperti UI dan UX, perangkat lunak perantara (middleware), atau basis data, bukan berdasarkan domain bisnis tertentu.
-
Aplikasi melibatkan tanggung jawab domain. Layanan yang mencakup konteks yang dibatasi bisa lebih sulit untuk dipelihara, memerlukan upaya pengujian yang lebih besar, dan memerlukan banyak tim domain untuk berpartisipasi dalam pembaruan perangkat lunak.
-
Dependensi domain, seperti pustaka entitas domain, dibagikan di seluruh layanan sehingga perubahan untuk satu domain layanan memerlukan perubahan pada domain layanan lainnya
-
Kontrak layanan dan logika bisnis tidak mengekspresikan entitas dalam bahasa domain yang umum dan konsisten, sehingga menghasilkan lapisan terjemahan yang merumitkan sistem dan meningkatkan upaya debugging.
Manfaat menjalankan praktik terbaik ini: Aplikasi dirancang sebagai layanan independen yang dibatasi oleh domain bisnis dan menggunakan bahasa bisnis umum. Layanan dapat diuji dan dapat di-deploy secara independen. Layanan memenuhi persyaratan ketahanan khusus domain untuk domain yang diterapkan.
Tingkat risiko yang terjadi jika praktik terbaik ini tidak dijalankan: Tinggi
Panduan implementasi
Keputusan berbasis domain (DDD) adalah pendekatan dasar perancangan dan pembangunan perangkat lunak berdasarkan domain bisnis. Bekerja dengan kerangka kerja yang ada memudahkan pembuatan layanan yang berfokus pada domain bisnis. Saat bekerja dengan aplikasi monolitik yang ada, Anda dapat memanfaatkan pola penguraian yang menyediakan teknik-teknik yang sudah lazim untuk memodernisasi aplikasi menjadi layanan.
Keputusan berbasis domain
Langkah implementasi
-
Tim dapat menyelenggarakan lokakarya event storming
untuk mengidentifikasi peristiwa, perintah, agregat, dan domain secara cepat dalam format catatan tempel ringan. -
Setelah entitas dan fungsi domain dibentuk dalam konteks domain, Anda dapat membagi domain Anda ke dalam layanan-layanan menggunakan konteks yang dibatasi
, dengan mengelompokkan entitas dengan fitur dan atribut yang serupa. Dengan model yang dibagi ke dalam konteks, muncul templat untuk membatasi layanan mikro. -
Misalnya, entitas situs web Amazon.com dapat meliputi paket, pengantaran, jadwal, harga, diskon, dan mata uang.
-
Paket, pengantaran, dan jadwal dikelompokkan ke dalam konteks pengiriman, sedangkan harga, diskon, dan mata uang dikelompokkan ke dalam konteks harga.
-
-
Mengurai monolit menjadi layanan mikro menjelaskan pola-pola untuk pemfaktoran ulang layanan mikro. Menggunakan pola-pola penguraian berdasarkan kemampuan bisnis, subdomain, atau transaksi selaras dengan pendekatan berbasis domain.
-
Teknik-teknik taktis seperti konteks gelembung
memungkinkan Anda memasukkan DDD di dalam aplikasi yang ada atau aplikasi warisan tanpa penulisan ulang di awal dan komitmen penuh terhadap DDD. Dalam pendekatan konteks gelembung, konteks terbatas yang kecil dibuat menggunakan pemetaan layanan dan koordinasi, atau lapisan antikorupsi , yang melindungi model domain yang baru ditentukan dari pengaruh eksternal.
Setelah tim melakukan analisis domain dan menentukan entitas serta kontrak layanan, mereka dapat memanfaatkan layanan AWS untuk menerapkan desain berbasis domain mereka sebagai layanan berbasis cloud.
-
Mulai pengembangan Anda dengan menentukan pengujian yang menggunakan aturan bisnis domain Anda. Pengembangan berbasis pengujian (TDD) dan pengembangan berbasis perilaku (BDD) membantu tim menjaga layanan tetap fokus pada pemecahan masalah bisnis.
-
Pilih layanan AWS
yang paling memenuhi persyaratan domain bisnis dan arsitektur layanan mikro Anda: -
AWS Nirserver
memungkinkan tim Anda untuk fokus pada logika domain tertentu, bukan pada pengelolaan server dan infrastruktur. -
Kontainer di AWS
menyederhanakan pengelolaan infrastruktur Anda, sehingga Anda dapat fokus pada persyaratan domain Anda. -
Basis data yang dirancang khusus
membantu Anda mencocokkan persyaratan domain Anda dengan jenis basis data yang paling sesuai.
-
-
Membangun arsitektur heksagonal di AWS menguraikan kerangka kerja untuk membangun logika bisnis menjadi layanan yang bekerja mundur dari domain bisnis untuk memenuhi persyaratan fungsional dan kemudian melampirkan adaptor integrasi. Pola-pola yang memisahkan detail antarmuka dari logika bisnis dengan layanan AWS membantu tim untuk berfokus pada fungsionalitas domain dan meningkatkan kualitas perangkat lunak.
Sumber daya
Praktik terbaik terkait:
Dokumen terkait:
Contoh terkait:
Alat terkait:
