Get best of the week

Merancang konteks terbatas dengan Kanvas Konteks Terbatas: resep lokakarya

Di antara topik konferensi TechLead Conf 2020 yang akan datang akan menjadi diskusi rinci tentang Domain-Driven Design dan EventStorming. Selain menyiapkan laporan 2-slot oleh Konstantin Gustov tentang DDD , laporan oleh Sergey Baranov tentang EventStorming, dan mitap di mana kami akan membuat radar DDD, kami memutuskan untuk menerjemahkan artikel tentang salah satu metode paling populer untuk merancang konteks terbatas.

Bagaimana memecah sistem besar menjadi komponen yang lebih kecil dan lebih mudah dikelola? Saya sering ditanya pertanyaan ini, jadi saya mengumpulkan pengetahuan saya di artikel ini.

Dalam DDD, sistem besar didekomposisi menjadi konteks terbatas (komentar oleh penerjemah: selanjutnya akan disebut sebagai konteks terikat) , yang menjadi batas alami - seperti layanan mikro dalam kode dan sebagai tim dalam suatu organisasi.

Tidak ada cara untuk dengan cepat dan mudah menentukan batas-batas baik dari konteks terbatas. Ini membutuhkan pengetahuan yang luas dan mendalam tentang bisnis dan bidang studi. Format lokakarya ini dirancang untuk memenuhi kedua kebutuhan ini dan menggunakan dua alat untuk menemukan desain sistem yang paling efektif: EventStorming dan Bounded Context Canvas.

gambar

“Saya mengembangkan kanvas ini dalam proses melakukan lokakarya DDD di acara-acara publik dan sesi perusahaan. Jangan ragu untuk mengubah strukturnya jika Anda menemukan format yang paling cocok untuk Anda. "

resep


Resep utama terdiri dari:

  1. EventStorming (minimal 1 jam).
  2. Memodelkan kandidat untuk konteks terbatas (minimal 30 menit).
  3. Memodelkan aliran pesan domain (setidaknya 30 menit).
  4. Kanvas Konteks Berbatas (minimal 90 menit).
  5. Membuat peta kontekstual (setidaknya 45 menit).

Sebagai titik awal, saya sarankan mengalokasikan satu hari penuh untuk lokakarya ini. Ini akan membantu Anda memahami berapa banyak waktu yang Anda perlukan untuk melakukan lokakarya dengan benar. Jika mahal (menyita waktu) untuk mengumpulkan semua orang, cobalah untuk segera mengalokasikan dua hari untuk menyelesaikan semuanya.

Idealnya, peserta harus ahli materi pelajaran dan pakar teknis. Jika ini sulit untuk diatur, maka cobalah untuk memastikan bahwa pakar domain berada di bengkel setidaknya selama satu jam pertama.

Prinsip dasar pemodelan


Untuk melakukan sesi dengan para ahli, Anda membutuhkan ruang yang luas. Jika Anda memilih audiens kecil, kemungkinan besar Anda akan kecewa dengan hasilnya. Setiap kelompok yang terdiri dari 4 orang membutuhkan setidaknya 4 meter di dinding.

Saya akan menjelaskan metodologi saya dalam bentuk bebas, tanpa peraturan ketat. Namun, perlu diingat:
“Kami terus beralih antara ruang masalah dan ruang solusi. "Kami mencari informasi, membuat model, mencari informasi tambahan, memperbarui model, dll."
Dan poin penting lainnya: tujuan sesi ini adalah untuk mengembangkan opsi dan mengembangkan kemampuan untuk menawarkan opsi yang lebih baik di masa depan.

1. EventStorming


Untuk merancang suatu sistem, Anda memerlukan dua hal: gagasan umum yang cukup bagus tentang keseluruhan sistem dan pemahaman yang cukup mendalam tentang perincian di setiap bidang. Untuk melakukan ini, mari kita mulai dengan EventStorming .

EventStorming adalah metode desain kolaboratif yang memungkinkan Anda untuk mensimulasikan area masalah besar dari awal hingga selesai, dan juga memungkinkan Anda untuk menelusuri sejumlah besar detail jika diperlukan.

gambar

Jika ini adalah pertama kalinya Anda melakukan ini, saya sarankan Anda menyisihkan 1-2 jam di EventStorming. Setelah menyelesaikan EventStorming, saya sarankan membagi menjadi kelompok 4 orang.
Di TechLead Conf 2020, Sergey Baranov akan berbicara tentang pengalaman praktis dengan EventStorming .

2. Cari kandidat untuk konteks terbatas


Setelah domain Anda dimodelkan secara luas dan mendalam di EventStorming, Anda bisa mulai mengelompokkan dan menggabungkan fragmen dalam konteks terbatas.

gambar

Ada banyak metode untuk menentukan konteks terbatas. Saya sarankan memulai dengan yang berikut:

  • Mulailah dengan nilai - identifikasi bagian inti dari domain yang paling berharga bagi bisnis.
  • Mulailah dengan yang sederhana - buat model naif dengan memecah garis waktu menjadi langkah-langkah berurutan.
  • Cari peristiwa penting - peristiwa bisnis yang memengaruhi berbagai bagian proses bisnis.

Untuk pertama kalinya, habiskan tidak lebih dari 30 menit untuk tugas ini. Undang grup untuk membuat model konteks terbatas asli sebagai titik awal. Itu tidak harus sempurna dan tidak mungkin menjadi solusi akhir.

Keluaran harus dalam daftar nama konteks terbatas pada flipchart atau kertas. Anda tidak dapat secara fisik mengubah EventStorming jika Anda memiliki beberapa grup.

Langkah selanjutnya


Anda dapat segera melihat beberapa cara untuk memodelkan sistem. Untuk saat ini, pilih salah satu dari mereka untuk bekerja dan tulis model yang mungkin lainnya (mereka akan berguna nanti). Anda juga dapat memahami bahwa Anda kehilangan informasi domain. Jika demikian, lakukan putaran EventStorming lainnya.

3. Pemodelan aliran pesan domain


Salah satu cara untuk memvalidasi desain Anda dan mencari poin peningkatan adalah dengan memvisualisasikan interaksi konteks terbatas dalam skenario sistem bisnis lengkap.

Jika aliran domain ternyata rumit, dengan sejumlah besar ketergantungan dan koneksi dua arah, maka desain Anda rapuh dan perlu analisis lebih lanjut.

Ada banyak metode visualisasi yang dapat digunakan untuk memodelkan aliran dan kasus penggunaan, termasuk diagram urutan UML dan diagram kasus penggunaan UML. Saya sarankan menggunakan opsi pendongeng domain .

Saat memodelkan aliran pesan dari domain subjek, konteks terikat adalah aktor dalam cerita. Dengan demikian, sebuah cerita khas dimulai dengan pengguna yang berusaha mencapai beberapa tujuan, dan interaksi antara konteks yang terbatas ditujukan untuk memberikan solusi kepada pengguna.

gambar
Contoh fiksi dari aliran pesan domain

Pemodelan aliran domain strategis memungkinkan Anda untuk mendapatkan umpan balik tentang konteks terbatas yang diusulkan. Ini menunjukkan bagaimana konteks berkolaborasi satu sama lain dan bergantung satu sama lain untuk menyelesaikan proses bisnis yang lengkap. Ini dapat membantu menemukan desain alternatif.

Pertanyaan yang harus Anda tanyakan pada diri sendiri adalah apakah deskripsi setiap konteks terikat cocok dengan peran yang dimainkannya dalam aliran domain. Jika tidak, kemungkinan bahwa batas nama atau konteks memerlukan desain ulang.

Langkah selanjutnya


Karena aliran domain Anda menentukan hubungan antara konteks yang dibatasi, Anda dapat segera melihat kelemahan desain yang jelas. Anda dapat kembali ke tindakan sebelumnya dan memperbarui kandidat untuk konteks terbatas atau melakukan iterasi kedua dari EventStorming. Anda juga dapat menuliskan pemikiran Anda tentang desain dan mengumpulkan informasi lebih lanjut tentang langkah-langkah selanjutnya sebelum memulai mendesain ulang.

4. Kanvas Konteks Terbatas


Tahap desain berikutnya adalah pengembangan kandidat untuk konteks terbatas, menggunakan detail kriteria desain utama. Tim Anda harus memilih konteks terbatas yang Anda anggap paling penting. Batasi diskusi hingga maksimal 3 menit. Tidaklah penting untuk menjadi 100% akurat.

Sekarang gambar Kanvas Konteks Terikat dan ikuti langkah-langkah ini untuk mengisi rinciannya. Saya sarankan menggunakan 1 lembar flipchart atau kertas dengan ukuran yang sama.
Setelah menyelesaikan langkah-langkah ini, ulangi prosesnya sampai Anda telah mengidentifikasi semua konteks Anda yang terikat. Cobalah untuk membagi waktu Anda secara merata antara kandidat yang diidentifikasi untuk konteks terbatas.

4.1 Definisi konteks umum


Mulailah dengan mendefinisikan nama konteks Anda yang terbatas dan deskripsinya. Deskripsi harus menunjukkan tujuan konteks dalam domain dan perannya dalam bisnis, dan bukan detail implementasi.

Selanjutnya, Anda perlu membuat klasifikasi strategis. Apakah konteks terikat adalah bagian utama dari sistem, elemen tambahan, yang umum atau yang lainnya? Baca posting Vlad jika Anda perlu bantuan memilih.

gambar
Sebagai contoh, Kanvas Konteks Terikat diisi setelah melalui langkah 1.

Langkah selanjutnya


Jika Anda tidak dapat menemukan nama yang jelas, atau menulis deskripsi yang koheren, akurat, atau istilah Anda untuk Bahasa Ubiquitous (UL) ambigu, anggap ini sebagai umpan balik untuk desain Anda. Pertimbangkan untuk mendesain ulang perbatasan, atau membuat catatan dan kembali lagi nanti (biasanya lebih baik kembali lagi nanti).

4.2 Klarifikasi aturan bisnis dan pembentukan bahasa yang sama


Sekarang kembali ke EventStorming dan lihat catatan untuk konteks terbatas ini. Temukan aturan dan kebijakan bisnis yang paling penting, kemudian cobalah untuk memilih 3 yang paling penting dan menambahkannya ke kanvas.
Konstantin Gustov di TechLead Conf 2020 akan berbicara tentang pengalaman bertahun-tahun bekerja dengan Bahasa Ubiquitous dan komponen DDD lainnya di Raiffeisen.
Ini juga merupakan saat yang tepat untuk mencari kata atau frasa bisnis utama untuk menambahkannya ke kanvas di bagian Bahasa yang Dapat Dideteksi Anda akan terus menambahkan kata dan frasa sepanjang lokakarya, sekarang ini hanya titik awal.

gambar

4.3 Analisis Fitur


Langkah selanjutnya adalah mengeksplorasi kemungkinan yang disediakan oleh konteks terbatas. Ini tidak hanya mengklarifikasi apa yang dia lakukan, tetapi juga memberikan banyak umpan balik untuk desain. Anda dapat mengajukan pertanyaan seperti:

  • Apakah konteks ini dipenuhi dengan tanggung jawab?
  • Apakah peluang terlihat terkait?
  • Apakah kemampuannya sesuai dengan nama dan deskripsi konteks?
  • Bagaimana jika kita memindahkan peluang ini keluar dari konteks?

Mulailah mendefinisikan peluang dengan memperkenalkan antarmuka publik. Apa yang dapat diminta konsumen dari konteks terbatas ini dan perintah apa yang dapat mereka gunakan? Gunakan aliran data domain untuk melihat apa yang dibutuhkan konsumen dari konteks terbatas ini.

Tidak semua fitur diaktifkan oleh perintah dan permintaan dari luar. Beberapa fitur dapat diluncurkan dari dalam. Misalnya, tugas yang dijadwalkan. Terkadang Anda mungkin memperhatikan bahwa peluang dikelompokkan, misalnya, perintah, permintaan, dan pemberitahuan. Jika demikian, letakkan mereka di atas kanvas dan beri nama kluster.

Anda mungkin merasa bahwa tanggung jawab itu tidak pantas dan harus terkait dengan konteks terikat lainnya. Jika demikian, pilih dengan tanda pengenal pada stiker.

gambar

Langkah selanjutnya


Jika Anda merasa sulit untuk menentukan kemampuan konteks atau merasa bahwa beberapa di antaranya hilang, saya sarankan kembali ke EventStorming dan memodelkan konteks terbatas ini secara lebih rinci dengan fokus pada menemukan kemampuan yang diperlukan untuk konteks atau layanan lain.

Kemampuan pendalaman [opsional]


Susun setiap peluang di kanvas Anda untuk fitur tambahan. Detail tambahan ini akan membantu Anda menemukan model alternatif. Jika tidak ada ruang yang cukup di kanvas untuk bagian-bagiannya, temukan selembar kertas lain atau ruang di dinding. Anda bisa masuk sebanyak mungkin lapisan lebih dalam sesuai keinginan Anda.

4.4 Ketergantungan


Ketergantungan diperlukan jika kita menginginkan modularitas, tetapi mereka juga menyebabkan berbagai masalah bisnis, teknis dan sosial. Oleh karena itu, penting untuk melihat ketergantungan, untuk memahami pengaruhnya, dan mempertimbangkan pilihan alternatif. Maka langkah terakhir dalam mendesain konteks terikat adalah untuk memastikan bahwa Anda menangkap semua dependensi utama konteks terikat Anda.

Melihat melalui hasil EventStorming dan diagram alir domain, identifikasi setiap ketergantungan yang memiliki konteks terbatas dan tuliskan informasi berikut:

  • nama konteks atau layanan lain yang dibatasi;
  • Penjelasan singkat tentang mengapa kecanduan itu ada
  • di mana ketergantungan: di dalam sistem ini atau dalam sistem eksternal (misalnya, layanan pihak ketiga);
  • tipe hubungan: ini adalah ketergantungan masuk (layanan lain tergantung pada konteks terikat ini), keluar (konteks terikat ini bergantung pada yang lain), antarmuka dua arah atau pengguna (ketergantungannya adalah beberapa jenis antarmuka pengguna).

Pertanyakan masing-masing dependensi: apakah diperlukan, berapa biaya dan manfaat ketersediaannya. Jika Anda dapat melakukannya tanpa itu, tandai ketergantungan dengan stiker kuning.

gambar

4.5 Kritik konstruktif


Ketika Anda telah selesai mengisi kanvas, luangkan beberapa menit untuk mengevaluasi secara kritis desain yang dihasilkan dari konteks terbatas Anda. Bagi ulasan Anda ke dalam kategori berikut:

  • Bagus : aspek desain yang Anda sukai.
  • Buruk : aspek desain yang tidak Anda sukai.
  • Tidak yakin : aspek desain yang tidak Anda yakini.

4.6. Refleksi dan pengulangan


Desain yang baik adalah iteratif. Sebelum pindah ke konteks terbatas berikutnya, mundur dan lihat gambaran besarnya. Sudahkah Anda mempelajari sesuatu yang bertentangan dengan desain Anda? Jika demikian, silangkan batas-batas yang diusulkan, dan kemudian terus merancang konteks terikat berikutnya.

Pada titik ini, tanyakan pada diri Anda apakah domain dimodelkan dengan cukup detail. Apakah sulit mengisi beberapa bagian kanvas? Jika demikian, coba putaran EventStorming lain di seluruh domain atau di beberapa bagian darinya.

5. Membuat peta konteks


Setelah membuat kanvas untuk setiap konteks terbatas dan mengumpulkan umpan balik desain, bagian selanjutnya dari sesi ini adalah kembali ke eksplorasi. Kali ini Anda memiliki serangkaian pengetahuan lengkap yang akan membantu Anda menemukan opsi desain terbaik.

Hasil dari latihan ini adalah kumpulan peta konteks dasar - visualisasi dari hubungan struktural antara konteks terikat dan diagram lain yang Anda anggap perlu, seperti diagram aliran domain. Setiap tim harus mengembangkan setidaknya 3 peta konteks, yang masing-masing akan menunjukkan opsi yang memungkinkan untuk membangun sistem.

gambar
Contoh peta konteks yang sangat akurat, untuk bengkel ini sudah cukup.

Kami akan mengadakan pertemuan di TechLead Conf 2020, di mana kami akan menganalisis berbagai teknik, pola dan anti-pola DDD dan mengumpulkan radar visual. Yang akan dipublikasikan setelah konferensi.
Kegiatan akhir dapat dilakukan dalam bentuk bebas. Tujuannya adalah untuk meninjau informasi yang dikumpulkan dan menggunakannya untuk mengembangkan sejumlah desain sistem. Sebagai titik awal, saya sarankan:

  • Lihat semua ulasan yang dikumpulkan untuk setiap konteks dan bereksperimen dengan ulasan "buruk" dan "tidak aman".
  • Ajukan pertanyaan "bagaimana jika" ...
  • "Bagaimana jika kita mentransfer kesempatan ini ke konteks terbatas lainnya?"
  • "Bagaimana jika kita mematahkan kesempatan ini dan memindahkan salah satu subfungsi ke konteks terbatas lainnya?"
  • "Bagaimana jika kita membagi konteks terbatas menjadi beberapa konteks?"
  • "Bagaimana jika kita mengambil kesempatan dari masing-masing dari ketiga konteks ini dan menggunakannya dalam konteks baru?"
  • "Bagaimana jika kita menduplikasi fungsi untuk menghapus kecanduan?"
  • "Bagaimana jika kita membuat layanan umum untuk mengurangi duplikasi dalam konteks yang berbeda?"
  • "Bagaimana jika kita mengisolasi peluang kunci yang benar-benar penting dan memindahkan sisanya ke tempat yang lebih damai, dalam konteks yang terpisah?"

Jika Anda lebih suka memvisualisasikan transformasi ini, ilustrasi berikut dapat membantu:

gambar

gambar

gambar

Penutupan bengkel


Untuk menyelesaikan sesi, masing-masing kelompok harus mempresentasikan pilihan peta konteks yang mereka buat dan mendiskusikan trade-off dari masing-masing desain. Anda perlu menjelaskan pilihan Anda, karena biasanya presentasi selama 5-10 menit biasanya sudah cukup.

Apa yang perlu Anda pertimbangkan dalam presentasi:

  • : .
  • : .
  • , , .

- TechLead Conf 8 9 . 32 , , , , DDD .

- — ( , ). , .

More articles:


All Articles