Apakah DDD sayap kanan?

Nov 29 2022

“DDD adalah sayap kanan!” Di balik pernyataan provokatif ini (ideal untuk mengadakan sesi unconf dan memiliki orang), Simon Chaveneau ingin bertanya pada dirinya sendiri tentang dampak Domain Driven Design (DDD) pada organisasi kami (Teknologi Produk) untuk memproduksi perangkat lunak. Hal ini terjadi selama non-konferensi pertama kami di Agicap, yang diselenggarakan untuk memungkinkan Produk dan orang-orang Teknologi bertemu untuk berdiskusi, belajar, berbagi, tertawa, tetapi di atas segalanya mendapatkan ketinggian dalam kaitannya dengan kehidupan kita sehari-hari.

“DDD adalah sayap kanan!”

Di balik pernyataan provokatif ini (ideal untuk mengadakan sesi unconf dan memiliki orang), Simon Chaveneau ingin bertanya pada dirinya sendiri tentang dampak Domain Driven Design (DDD) pada organisasi kami (Teknologi Produk) untuk memproduksi perangkat lunak. Hal ini terjadi selama non-konferensi pertama kami di Agicap, yang diselenggarakan untuk memungkinkan Produk dan orang-orang Teknologi bertemu untuk berdiskusi, belajar, berbagi, tertawa, tetapi di atas segalanya mendapatkan ketinggian dalam kaitannya dengan kehidupan kita sehari-hari.

Unkonferensi pertama kami di Agicap, 13 Okt 2022

Selama unconference, program ditetapkan oleh penonton. Ini dilakukan selama sesi “Market Place” awal di pagi hari. Selama pleno pertama hari ini, masing-masing dan setiap orang dapat mengambil perekat, spidol, dan kemudian menyampaikan sesi mereka di depan semua orang. Kemudian orang memposisikannya pada program hari itu (untuk info lebih lanjut tentang unconference ini, ada utas twitter ini )

Tapi mari kita kembali ke pokok bahasan dan sesi menarik yang diajukan oleh Simon.

Versi Prancis dari "DDD adalah sayap kanan!"

Pemerintahan milik pribadi?

Singkatnya nada awal Simon: jika seluruh bagian dari IS kami milik tim — masing-masing bertanggung jawab atas satu atau lebih Bounded Context (BC) — bukankah kita dihadapkan dengan versi perangkat lunak dari properti pribadi (dengan kawat berduri di sekitar BC, dll. .)? Oleh karena itu provokatifnya “ DDD adalah barang sayap kanan! ”

Dan dengan pertanyaan pelengkap: “Bukankah kita akan lebih efisien dengan organisasi yang didasarkan pada tim unggulan? (dengan semua orang dapat bekerja pada semua BC menuju kasus penggunaannya)”

Yah… Saya harus mengakui bahwa sesi ini ternyata jauh lebih bermanfaat daripada yang saya harapkan sebelumnya karena diskusi yang sangat menarik terjadi tentang mode organisasi Produk / Teknologi kami.

Namun daripada merinci jalur yang diambil oleh sesi ini di mana kami sangat banyak (pasti menarik untuk dijelaskan dalam konteks posting lain), saya akan langsung menjelaskan apa yang telah saya pertahankan dan pikirkan tentang subjek tersebut.

Beberapa pengamatan

Perangkat lunak yang efektif adalah perangkat lunak yang selaras dengan tantangan bisnis . Dengan diselaraskan, yang kami maksud adalah perangkat lunak yang meminjam istilah yang tepat dari bidang domain, yang dengan tepat mengartikulasikan konsep kunci bisnis dan meminimalkan kerumitan tak disengaja yang dibawa oleh masalah teknis. Ini adalah salah satu tantangan utama Domain Driven Design (DDD), seperti yang dijelaskan di sini dalam 3 menit .
Hukum Conway bukanlah pilihan yang bisa dipilih untuk tidak diambil.‍♂️ Hukum ini bekerja seperti hukum fisika tertentu seperti gaya tarik gravitasi. Kita dapat mencoba melawannya ;-) tetapi itu masih berlaku di bumi. Hukum Conway adalah hukum tahun 1967 yang menyatakan bahwa
"Setiap organisasi yang merancang sistem (didefinisikan secara luas) akan menghasilkan desain yang strukturnya merupakan salinan dari struktur komunikasi organisasi."
Dengan kata lain, arsitektur perangkat lunak merupakan hasil dari mode komunikasi orang-orang yang terlibat dalam perancangannya. Misalnya, kompiler yang dikembangkan oleh 3 tim kemungkinan besar akan bekerja dalam 3 lintasan atau memiliki 3 modul berbeda.
Inverse Conway Maneuver (ICM) membiarkan Anda berpikir seseorang dapat mengontrol hukum Conway. Pada awalnya, manuver terbalik ini dengan bijak direkomendasikan untuk “ mendobrak silo yang membatasi kemampuan tim untuk berkolaborasi secara efektif”. Namun telah diubah selama bertahun-tahun menjadi rekomendasi konyol: " ubah organisasi Anda untuk mencapai arsitektur target Anda ". Konyol karena ingat: "Budaya makan strategi saat sarapan". Info lebih lanjut di sini di utas yang menarik itu.
Desain Berbasis Domain tidak memaksakan organisasi apa pun. Ini memberi kunci untuk memungkinkan kelangsungan hidup, termasuk dalam kasus organisasi disfungsional (dengan tim yang berperang atau mengabaikan satu sama lain). DDD membantu kita memahami masalah kekuasaan dan masalah sosial antar tim. Akibatnya, ini lebih merupakan alat pembebasan melawan determinisme kita ( maka saya akan mengatakan alat sayap kiri ;-)
Di sisi lain, DDD memberi kita alat untuk dapat merancang perangkat lunak yang efisien yang selaras mungkin dengan domain. Diantaranya konsep Bounded Context (BC), yang mengusulkan kita untuk merancang model untuk digunakan, dan untuk mengelilinginya serta melindungi dari kebingungan/teman palsu/kesalahpahaman yang dihasilkan dari konteks lain.
Untuk penyelarasan dan efisiensi yang lebih baik, DDD juga sangat menyarankan agar kami secara teratur menantang visi dan pemodelan solusi kami. Ini juga berarti merevolusi dan mengubah model dari waktu ke waktu mengikuti momen eureka (disebut Terobosan Desain ). Itulah mengapa kami secara teratur mengadakan sesi Peta konteks di sini yang terus-menerus menyempurnakan visi kami di lapangan dengan orang-orang Produk.
Tim pengembang memiliki keseimbangan yang rapuh. Dibutuhkan sekitar 6 bulan hidup bersama dan hubungan antarpribadi agar tim pengembang menjadi benar-benar efektif. Anda menambahkan atau menghapus satu orang dari tim ini dan tim tersebut bukan lagi tim yang sama (lihat Dynamic Reteaming ). Dalam hal efisiensi, saya lebih suka tim yang tetap bersama dan berganti mata pelajaran, daripada tim yang meledak/dibagi ulang sesuai mata pelajaran. Tentu saja, jika seseorang muak dengan timnya atau subjeknya, segala sesuatu harus dilakukan untuk memungkinkan mereka berganti tim (menjadi baik secara pribadi bahkan lebih penting untuk efisiensi kolektif kita)
Organisasi kami saat ini dan tim kami di sini di Agicap agak berafiliasi dengan satu atau lebih Konteks Terikat untuk memperhitungkan kerumitan masalah dan memanfaatkan keahlian bisnis kami masing-masing secara minimal. Dari waktu ke waktu, beberapa tim mungkin memiliki cakupan yang terlalu besar dan kami perlu memotong dan menetapkan Konteks Batas kami dengan lebih baik. Di sisi lain, pembagian BC ini harus tetap terkait dengan konsep bisnis (ingat DDD)
Tidak ada yang melarang memiliki tim fitur dalam organisasi yang melakukan DDD , selama semua orang menghormati batasan Konteks yang Dibatasi.
Untuk saat ini, kami sangat menyukai praktik Swarming (semacam gugus tugas yang dibentuk dengan orang-orang dari beberapa tim tetapi akuntabilitas dan kepemilikan artefak akhir (alat, api, perpustakaan) ditentukan sejak awal. Ini membantu untuk menghindari sindrom “Bagus, kita telah melakukan sesuatu bersama, tapi siapa yang akan mempertahankannya sekarang?!?”). Di luar keefektifannya dalam mendapatkan orang yang tepat untuk berkolaborasi tergantung pada subjeknya, swarming membawa banyak modal sosial ke organisasi kami dengan mempromosikan hubungan interpersonal lintas tim untuk sementara (sangat berguna untuk masa depan ketika semua orang kembali ke tim mereka).
Organisasi Produk kami saat ini ditetapkan pada 1 Manajer Produk (PM) per tim pengembang, tetapi mungkin akan menarik jika PM lebih dikaitkan dengan subjek bisnis daripada dengan tim mereka?

Akhirnya, saya akan mengatakan bahwa tidak ada lagi peluru perak dalam organisasi daripada yang kita miliki di dev. Umpan balik, pertanyaan, dan eksperimen terus-menerus adalah rekan kami di jalur peningkatan berkelanjutan ini untuk secara efektif membuat perangkat lunak yang relevan bagi pengguna kami.