Setahun yang lalu, Maxim Arshinov (marshinov) membuat presentasi "Desain Instan". Laporan hebat, pembicara karismatik, bahan yang bermanfaat di bagian akhir. Laporan ini mengubah pemahaman saya tentang apa yang saya lakukan - siapa di antara kita yang belum mencoba menerapkan arsitektur pipa secara intuitif? Dan kemudian ada solusi elegan dikalikan dengan DDD! Ini memulai perjalanan saya sebagai penginjil dalam desain khusus domain.

DotNext 2019 Moskow akan segera hadir. Seperti biasa, kami menunggu tinjauan fitur baru, pertukaran pengalaman, praktik terbaik, solusi arsitektur - untuk ini kami semua menyukai konferensi. Dalam daftar laporan ada wokshop "The Shine and Poverty of the Subject Model," yang menarik perhatian saya. Kutipan dari halaman:

Fowler dan Evans menganggap model anemia sebagai antipattern. Namun, banyak basis kode yang telah bekerja dengan pembicara diimplementasikan dalam gaya model anemia. Laporan ini dikhususkan untuk membandingkan kekuatan dan kelemahan dari kedua pendekatan dan rincian yang tidak jelas dari implementasi model domain dalam paradigma OOP dan gaya fungsional.

Produksi itu sendiri membuat orang berpikir bahwa krisis telah muncul dalam pengembangan gerakan DDD. Analisis kecil dari disfungsi penggunaan dan alasan untuk distorsi seperti itu di bawah potongan.

Disfungsi penggunaan desain berorientasi subjek

Situasi saat ini memiliki beberapa perkembangan historis. Mari kita pertimbangkan secara bertahap bagaimana situasi berkembang.

Promosi

Maxim, menurut saya, adalah pengembang paling terkenal di komunitas, yang selama bertahun-tahun secara kompeten mempromosikan DDD, berbicara tentang konsep, gunakan. Hormatilah dia dan pujilah! Dan saya memberikan Arshinov sebagai contoh, hanya karena saya menganggapnya sebagai pembicara terbaik dotnext saat ini.

Disfungsi # 1: Profitabilitas

marshinov telah menulis beberapa artikel tentang biaya penerapan praktik DDD. Kesimpulannya sederhana - desain berorientasi subjek mahal. Dan penilaiannya adil - Evans sendiri dalam bukunya mencatat bahwa tim harus sangat terampil, dan karenanya mahal. Selain itu, ini adalah peningkatan berkelanjutan, yang mahal untuk bisnis. Yah mengungkap artikel topik ini oleh Martin Fowler tentang biaya arsitektur . Saya berani berasumsi bahwa pertanyaan tentang seberapa banyak bisnis yang ingin menghabiskan sumber daya adalah solusi dari masalahnya, pertama-tama, untuk dirinya sendiri. Dan pelanggan tidak memecahkan masalah besar sendiri, maka bahkan SOLID tidak akan dapat menjualnya.

Sangat penting untuk memahami pertentangan persyaratan bisnis dan keputusan arsitektur. Bisnis membutuhkan solusi termurah yang akan memenuhi kebutuhan mereka (dan lebih baik untuk pertama kali dan selamanya). Tim ingin membuat alat dan solusi yang paling tepat, cepat dan indah memecahkan masalah bisnis, tetapi terutama tugas adaptasi terhadap perubahan. Sifat dari kebutuhan ini (pada kenyataannya, kontradiksi kutub) sangat dialektis, yang pada gilirannya berarti bahwa tidak mungkin untuk mewujudkan persyaratan yang rumit tanpa menguraikan arsitektur, dan kondominium tidak dapat dibangun daripada rumah anjing. Tidak, tentu saja semuanya mungkin. Tetapi kenyataannya adalah bahwa tuntutan yang tinggi di satu sisi menimbulkan yang sesuai di sisi lain. Seperti kelemahan patologis dari satu sisi, ia membatasi yang lain.
Jadi, dalam upaya untuk mencocokkan bisnis, bencana kedua terbentuk ...

Disfungsi # 2: Desain Instan alias Model Anemik alias Persetujuan

Jelas, komunitas programmer tertentu sedang berusaha membawa ke banyak praktik desain berorientasi subjek yang lebih murah, mengurangi biaya dan menerapkan teknik baru: RailwayProgramming, Pipelines, Anemic model. Sebuah pendekatan yang keren, banyak saran, ini dapat diajarkan kepada setiap programmer: "di sini Anda memiliki SeedWorks dengan antarmuka, mengimplementasikannya dan semuanya akan terjadi." Dan itu berhasil! tapi ini bukan DDD.

Anda tidak begitu mengerti Evans.

• Siapa yang tidak memuji Klopstock? Tetapi apakah semua orang akan membacanya? Tidak. Kami ingin lebih dihormati, tetapi membaca lebih rajin! (Mengurangi).

Saya akan jelaskan sekarang.

Model anemia adalah antipattern

Faktanya adalah bahwa dalam sains ada dua metode penelitian - deskriptif dan analitik (halo Adam Smith). Ketika kita membuat model Anemik, kita hanya menggambarkan apa yang kita lihat, dan hidup dengannya apa adanya. Ini mencerminkan bisnis dan cukup untuk mewujudkan peluang bisnis. Prinsip penting yang diuraikan oleh Evans bukanlah membuang-buang sumber daya pada sistem yang ideal, tetapi untuk mensimulasikan proses sebagaimana adanya, dan baru kemudian memulai refactoring yang mendalam. Dan pada titik mana dengan Model Anemik kita dapat beralih ke refactoring yang mendalam? Apakah ini seharusnya memulainya? Tampaknya bagi saya bahwa jawabannya akan negatif, dan model di sini tetap sebagai atavisme.

Itu hanya modelnya sendiri tidak penting! Pola taktis tidak penting! Konteks terbatas, satu bahasa, dan struktur skala besar adalah penting. Itulah mengapa perlu untuk mendekati entitas bisnis dari sisi analitis, menggambarkan akar agregasi, objek nilai, metode bisnis, dan sebagai hasilnya, memahami batasan konteks yang terbatas.

Di satu sisi, model anemik dan solusi murah bagus, karena pemrogram pemula akan memiliki pemahaman tentang dimensi baru dalam pemrograman - objek bisnis. Namun, mengambil posisi yang sama Anda lakukan buruk untuk diri sendiri. Dengan mempekerjakan programmer yang lebih lemah setiap kali dapat melakukan hal yang sama seperti copy-paste, apakah Anda memiliki argumen untuk bisnis untuk mencari karyawan yang lebih kuat?

Tapi itu tidak bisa berakhir dengan akhir dari ide DDD yang memalukan.

Disfungsi # 3 Kehidupan setelah benda bisnis alias komplikasi alat.

Pada musim semi tahun 2019, Maxim dan Wagib memberi tahu kami tentang bagaimana fitur F # di C # tidak datang, tentang bagaimana membuat model dengan benar dalam F # lebih mudah, tentang bagaimana dalam fungsionalisme tidak melanggar OOP. Sekarang massa dapat percaya bahwa DDD tidak hanya tidak terjangkau untuk memesan musik, tetapi tidak untuk semua manusia, tetapi hanya mereka yang tahu pemrograman fungsional.

Dengarkan di mana mereka semua mengemudi - sekarang desain yang berorientasi subjek mahal, Anda dapat secara efektif menulis hanya dalam F #, dan umumnya bekerja kadang-kadang, kadang-kadang. Tidak ada kesan samar bahwa dengan cara ini penulis buku dan artikel mengalihkan kita dari yang paling penting di DDD, memikat permainan dengan pola taktis yang ideal. Dan mereka harus cantik dan dijilat, kalau tidak ...

Tentu saja tidak ada jalan lain. Semua abstraksi ini penting dalam percakapan BrainSrorm, ketika semua orang perlu memahami semuanya dengan sangat jelas. Atau jika Anda menemukan manajer dan analis yang akan melihat kode Anda - satu bahasa (jika kode tersebut adalah UL).

Namun, seperti yang disebutkan di atas, yang sebaliknya akan mencari caranya sendiri. Pendekatan ini berakar di mana bisnis bersedia membayar untuk pengembangan kode yang tidak terlihat secara fungsional - ini hanya ceruk pasar, bukan aturan.

Apa yang benar-benar menjijikkan di sini adalah sifat manusia yang sederhana dari sikap terhadap prestasi - orang menghargai prestasi tersebut dalam diri mereka sendiri, tanpa memberi mereka formulir dan aplikasi terapan. Dan di sini daftarnya mungkin panjang. Einstein memberi kita STO, GR, FE, dia adalah ilmuwan yang sangat baik, tetapi tanyakan kepada orang kebanyakan tentang gerakan relativistik, waktu - dia tidak membutuhkan Einstein, tetapi dalam percakapan "pintar" orang dapat menyebutkan bahwa semuanya relatif. Tanyakan kepada seseorang tentang Freud, seorang psikolog hebat yang telah membuat kemajuan serius dalam sains, jika orang ini menggunakan psikologi, misalnya, untuk menafsirkan mimpi buruk kemarin - dia tidak akan, tetapi suatu hari dia akan menyebutkan seksualitas dan psikologi massa. Marx adalah orang yang membuat ilmu dari sosiologi dan sejarah, tetapi tidak ada yang membutuhkan sosialisme ilmiah, tetapi semua orang dapat berbicara tentang pajak progresif dan demokrasi jujur. Desain berorientasi masalah juga tidak memiliki bentuk - Eric Evans telah membuka ketinggian baru bagi kami, menyediakan alat yang sangat baik untuk mengurangi kompleksitas perangkat lunak, tetapi seolah-olah cara menggunakan DDD dan apa yang harus dilakukan tidak jelas, dan umumnya tidak berfungsi sama sekali.

Saya tidak tahu bagaimana sisanya, tetapi dengan desain yang berorientasi pada subjek Anda dapat memahami alasan kesalahpahaman.

Alasan krisis penggunaan

Prinsip-prinsip desain berorientasi subjek sangat menggoda, logis dan holistik. Semuanya dekat di sini - Agile, CI, SOLID, GRASP - semua yang terbaik yang dihasilkan oleh pengembang. Namun, tidak cukup hanya percaya pada DDD, atau bisnis, atau pengalaman. Banyak orang dari komunitas, hanya pengembang dari integrator dan kantor outsourcing, memiliki jejak nilai bisnis dalam pekerjaan mereka, dan dengan semua keinginan mereka tidak dapat mencoba metode dan praktik terkemuka, karena harga percobaan dan kesalahan ini tidak termasuk dalam daftar harga - ini adalah final yang sepenuhnya materialistis.

Sama sekali tidak ada yang tersisa untuk perintah seperti itu kecuali bagaimana membuat pemrograman menguntungkan, menggunakan pendekatan yang lebih sederhana, mempekerjakan pengembang lebih murah, tetapi model anemia dapat dikaitkan "setengah inci". Dan jika Anda adalah pengembang dari salah satu pengembang yang datang selama satu jam - Anda tidak memiliki prospek yang signifikan - Anda harus menyelesaikan pesanan, dan kreativitas hanya didorong pada github di proyek rumah. DDD bukanlah kemewahan bagi seorang arsitek, bukan pamer pelanggan - tingkat tim dalam Enteprise yang terpisah. Anda perlu menyadari hal berikut - saat Anda berada dalam hubungan produksi dengan mereka yang menjual pekerjaan terampil Anda kepada mereka yang membayar lebih baik, Anda hanya akan melakukan apa yang dibayar pelanggan - pelaksanaan tugas bisnis. Sayangnya, menguji praktik terbaik tidak selalu terletak pada bidang tugas-tugas ini.

Ringkasan

DDD selalu dapat dicoba jika Anda menggambarkan objek dunia nyata. Pendekatan ini dapat diterapkan dalam PHP, dan dalam VBA, dan 1C (dan pengembang berlaku). Masalah dalam menerapkan pendekatan ini agak pada bidang komunikasi antara orang-orang, dan teknologi lebih mungkin untuk membantu. Berkomunikasi, mencoba, mengajar orang lain! Tingkatkan softskill, solidaritas, kesatuan tujuan. DDD hanyalah teknik kerja tim.

Dan lain kali Anda berpikir tentang ke mana harus pergi untuk wawancara, pikirkan dengan hati-hati tentang apa yang Anda pilih - sebuah perusahaan tanpa ampun menjual kembali keterampilan Anda, atau yang benar-benar membutuhkan mereka untuk menyelesaikan masalah tertentu. Adalah kekuatan Anda untuk membantu perusahaan seperti itu menjadi lebih baik, untuk mencoba metode dan pendekatan proporsional, untuk membentuk tim yang bersatu, untuk memenuhi misi Anda sebagai programmer. Yang terakhir ini sangat penting, karena untuk teknologi dan barang baru, banyak yang telah melupakan tujuan asli dari profesi ini.

Meskipun demikian, tetap diharapkan bahwa dalam upaya untuk menyentuh praktik-praktik unggulan, DDD tidak akan diubah ke arah lain apa pun demi kenyamanan bagi pelanggan dan tim. Saya menantikan laporan mendatang.

PS Tujuan dari topik ini adalah undangan untuk berdiskusi. Tidak ada tujuan untuk meremehkan jasa anggota DDD. Dengan hormat, saya memperlakukan semua perwakilan, yang tidak menghilangkan masalah pembangunan.