Get best of the week

Apa yang dapat saya pelajari tentang Desain Berbasis Domain dalam 10 menit?

Mereka mengatakan bahwa Anda dapat melihat api tanpa henti, mengamati cara kerja orang lain, dan juga mempelajari DDD (Desain Didorong Domain, desain khusus domain). Tetapi jika Anda hanya memiliki 10 menit, Anda dapat membaca artikel ini dan pergi ke puncak, dan kemudian dengan tampilan yang cerdas, anggukan kepala Anda selama pembicaraan kecil.

Kami memutar dan mengulas DDD dari berbagai sudut, bersama dengan Andrei Ratushny, direktur teknis Ugra Internet Solutions.





Tentang perusahaan: Ugra Internet Solutions adalah perusahaan yang bergerak dalam otomatisasi proses bisnis di sektor komersial dan publik. Terletak di kota Khanty-Mansiysk. Dalam perkembangannya 12 orang.

1. Apa itu DDD, dapat dijelaskan bahkan kepada anak (atau pemasar)


DDD adalah pendekatan yang bertujuan untuk mempelajari bidang subjek perusahaan sebagai keseluruhan atau proses bisnis individu. Ini adalah pendekatan yang sangat baik untuk proyek-proyek di mana kompleksitas (kompleksitas) dari logika bisnis cukup besar. Penggunaannya dirancang untuk mengurangi kompleksitas ini sebanyak mungkin.

Di luar pendekatan DDD, ketika seorang programmer menulis kode, ia lebih memperhatikan teknologi dan infrastruktur, misalnya, cara mengirim pesan, cara menerimanya, menyandikannya, menyimpannya ke basis data, basis data mana.

Pendekatan DDD menunjukkan bahwa semua ini, tentu saja, penting, tetapi sekunder. Bisnis lebih penting dan harus didahulukan. Dan untuk membuat semua ini bekerja bersama, DDD mengajarkan kita (pengembang) untuk berbicara bahasa yang sama dengan bisnis. Bukan dalam bahasa pemrograman, tetapi dalam bahasa bisnis. Ini disebut dalam bahasa DDD Ubiquitous.

2. Chip DDD - Konteks Terbatas


Bounded Context adalah alat DDD kunci, itu adalah batas eksplisit di mana model domain ada. Ini memetakan satu bahasa ke dalam model perangkat lunak. Atas dasar konteks itulah Anda dapat membagi kode menjadi modul / paket / komponen sehingga perubahan di masing-masingnya memiliki efek minimal (atau nol) pada yang lain.

Untuk pengembang, pendekatan ini memungkinkan Anda untuk membuat perubahan pada kode tanpa takut bahwa di suatu tempat di tempat lain sesuatu akan pecah (misalnya, mengubah sesuatu di kasir dan tidak khawatir bahwa sesuatu akan jatuh dari kurir karena hal ini).

Untuk pemimpin tim, pendekatan ini memungkinkan kami untuk secara paralel memparalelkan kerja tim, yang secara signifikan dapat mempercepat pekerjaan di proyek.

Selain konteks yang terbatas, ada banyak hal seperti peta konteks, satu bahasa, hubungan antar konteks, peta terjemahan ... uhhh! Anda tidak akan menceritakannya dalam 10 menit, tetapi Anda dapat membaca buku "hijau".

3. Buku-buku umum tentang DDD: merah, biru dan hijau


DDD adalah pendekatan yang cukup lama. Penggunaannya tampaknya masuk akal dan cukup dibenarkan, tetapi untuk beberapa alasan masih belum tersebar luas, sedikit yang dikatakan tentang hal itu di konferensi. Apa yang salah dengan DDD ini?

Ada asumsi bahwa masalah utama adalah kurangnya materi pelatihan. Seluruh teori dijelaskan dalam beberapa buku: merah , biru dan hijau . Mereka mengatakan bahwa ada "buku merah lain" , tetapi masih sedikit yang melihatnya :) Buku

merah dan biru sangat sulit untuk dipahami bahwa di suatu tempat di tengah saya ingin membuang buku itu keluar jendela sambil berteriak: "Cukup omong kosong ini dari saya, lihat DDD yang tidak bisa dipahami ini! Saya akan pergi dan melakukan yang saya bisa. " Dan ini hanya tentang teori, dengan materi tentang praktiknya bahkan lebih rumit.

Karena itu, jika Anda masih memutuskan untuk mulai mempelajari literatur tentang DDD, yang terbaik adalah memulai dengan buku hijau. Di dalamnya, Vaughn Vernon menelusuri puncak-puncak pendekatan dan, dengan contoh-contoh sederhana, menunjukkan kelebihannya. Mereka mengatakan bahwa terjemahannya ternyata meragukan, jadi lebih baik untuk membaca dalam aslinya.

4. Bagaimana memahami bahwa sudah saatnya menerapkan DDD


Hitung jumlah use case untuk sistem Anda. Jika mereka berada di wilayah 10-15, maka logika bisnisnya tidak begitu rumit, dan Anda tidak dapat melakukan steam, jangan menggunakan DDD.

Jika Anda memiliki 30-50 atau lebih kasus UX, dan mereka sangat bersinggungan, masuk akal untuk berpikir tentang menggunakan DDD setidaknya di beberapa bagian sistem.

5. Bagaimana menerapkan DDD di perusahaan dari bawah ke atas


Bayangkan Anda adalah pengembang yang menyukai DDD, dan Anda berpikir bahwa di perusahaan Anda, pendekatan ini dapat diterapkan untuk membuat orang bahagia.

Memulai pengenalan gerilyawan DDD saja sulit. Pertama, pengetahuan mungkin tidak cukup untuk memulai proses. Kedua, dudes dari tim Anda mungkin berpikir bahwa Anda melakukan hal-hal bodoh dan akan menghancurkan segalanya dengan memasukkan tongkat ke roda.

Lebih baik memulai implementasi dengan membuat grup inisiatif: cobalah pendekatan bersama, pahami nuansa, dan pahami dalam praktik.

Hanya dengan begitu Anda dapat pergi ke arsitek atau insinyur teknis untuk menjelaskan nilai kepadanya. Tetapi ingat bahwa DDD tidak diperlukan di mana-mana. DDD memecahkan masalah khusus, jadi sangat penting untuk tidak berlebihan.

Pendekatan ini memiliki efek samping: jika orang bahkan mulai berjuang untuk DDD, maka mereka sudah akan mulai bertindak dalam paradigma "Membagi, membagi, mengurangi konektivitas dan mengikuti logika bisnis." Dan dari sini, perubahan positif akan dimulai: di suatu tempat kode akan ditulis lebih baik, di suatu tempat kecepatan akan meningkat. Pengetahuan ini tidak harus berubah menjadi kode dalam konteks dan artifak DDD lainnya. Kode mungkin tetap kode, tetapi akan menjadi lebih baik, dan kecepatan dan kualitas akan meningkat.

6. Bagaimana menerapkan DDD di perusahaan dari atas ke bawah


  1. Pastikan bahwa pendekatan ini akan membantu dalam kasus tertentu.
  2. Temukan seseorang dalam tim yang memiliki keterampilan arsitektur (dia akan membantu menentukan di mana dalam sistem jahitan yang akan dipotong).
  3. Undang praktisi DDD untuk mengajar Anda.
  4. . ! . , .

7. DDD


Tentu saja, melalui latihan. Hanya saja, jangan memberi tahu orang itu sebelumnya bahwa Anda mengajarinya DDD, jangan takut sebelumnya.

Biarkan orang itu datang dan mendapatkan teka-teki. Jangan katakan padanya bahwa itu DDD, biarkan dia melakukannya. Dia akan melakukan berdasarkan bagaimana dia memahami solid dan semua itu. Kemudian, ketika dia akan menyerahkan pekerjaan itu, dia perlu mengatakan: "Bung, sepertinya berhasil, tetapi perlu diperbaiki", dan menjelaskan kepadanya mengapa.

Jangan memaksakan membaca atau mempelajari segala sesuatu dengan sengaja. Bersikap interaktif dalam hal ini. Jadi seseorang dalam 3-5 bulan akan mulai memahami prinsip-prinsip dasar DDD: dari sudut pandang implementasi, dari sudut pandang teori. Dia akan mulai memahami pola lebih awal dengan mendekati artefak - peta konteks. Pada awalnya, orang tidak akan mengerti apa-apa, tetapi secara bertahap mereka akan dipotong, dan beberapa bahkan akan membaca buku.

8. Saya dapat DDD - jalur yang tidak penting untuk resume di Rusia


Jika Anda berada di Rusia dan tahu DDD - ini keren. Tetapi jauh dari kenyataan bahwa pengetahuan DDD itu sendiri berguna dalam pekerjaan. Sebaliknya, ini akan berfungsi sebagai indikator bagi pemberi kerja tentang tingkat perkembangan tinggi Anda sebagai pengembang. Bagaimanapun, keterampilan yang Anda peroleh dengan mempelajari pendekatan DDD mengembangkan Anda sebagai programmer dan sebagai desainer (arsitek).

Tetapi jika Anda berpikir tentang pindah ke luar negeri, maka garis seperti itu dalam resume dapat memiliki dampak positif. Di luar negeri, komunitas DDD jauh lebih besar, dan pendekatannya sendiri jauh lebih populer daripada kita. Terutama di Eropa.

9. Hubungan DDD dengan rambut wajah


Pengamatan: Orang yang mengerti DDD memakai janggut. Apakah ini berarti memiliki janggut adalah prasyarat untuk sukses di DDD? Bagaimana menurut anda?

10. Bahan yang berguna pada DDD



« ». , . , Miro, , Amazon, Microsoft, . .

:

More articles:


All Articles