Latihan DDD untuk pasukan robot telefon

Pengenalan

DDD ialah satu set metodologi dan satu set idea. Pelbagai jenis metamodel dan konsep nominal. Intipati mereka adalah "salah satu" penyelesaian yang sepadan dengan ideologi panduan, dan pemula mudah terperangkap oleh penampilan. Anda harus sentiasa memahami dengan jelas bahawa "semua model meta DDD dicipta untuk menyelesaikan jenis masalah tertentu dalam pembangunan sebenar." Apabila berhubung dengan pelbagai model meta, anda harus menjalankan pengesahan berdasarkan masalah yang dihadapi oleh perniagaan anda sendiri Ini akan membantu mengelakkan daripada terperangkap oleh perwakilan konsep dan kembali kepada intipati menyelesaikan masalah.

Latar Belakang

Pasukan seni bina data mula membangunkan robot telefon yang dipacu oleh keperluan perniagaan pada 2018, dan sudah hampir 5 tahun dalam sekelip mata. Pada masa ini, 100+ jenis robot berbeza telah dibina di bawah platform ini untuk menyediakan keupayaan panggilan keluar untuk peniaga syarikat, kereta terpakai, OEM, kewangan dan perniagaan BU lain, dengan ratusan ribu panggilan keluar setiap hari. Projek robot telefon telah mula terbentuk, tetapi ia juga menghadapi banyak cabaran dalam proses itu. Untuk menghadapi cabaran ini, pasukan kami akhirnya menggunakan pemikiran DDD untuk pembinaan semula dan pembangunan.

Dalam proses menggunakan DDD, pasukan seni bina data melaksanakan beberapa spesifikasi pembangunannya sendiri. Di sini saya ingin berkongsi beberapa pengalaman dan idea dengan anda, berharap ia boleh menjadi titik permulaan. Biar saya terangkan di sini Banyak model multivariate tidak dibincangkan dalam artikel ini, dan tiada kes khusus diberikan. Pertama, pertimbangkan isu panjang. Yang kedua ialah memahami idea DDD dan melaksanakannya dengan menggabungkan perniagaan masing-masing Tidak bermakna untuk memberi contoh dalam perniagaan saya. Selain itu, kes sebegini mudah didapati. Pada masa yang sama, saya merasakan adalah lebih bernilai untuk semua orang berkongsi masalah dan penyelesaian yang dihadapi oleh pasukan kami, proses pelaksanaan dan spesifikasi pembangunan yang telah kami bentuk. Pelajar yang berminat dengan DDD, ingin mengetahui lebih lanjut atau mempunyai pertanyaan tentang artikel ini dialu-alukan untuk menghubungi saya untuk perbincangan.

Di bawah, saya akan berkongsi dari bahagian ini: cabaran yang dihadapi dalam projek robot, sebab DDD ialah DDD, langkah untuk melaksanakan DDD, penambahbaikan kepada pasukan, konflik yang dihadapi dari teori hingga amalan, dan Penambahbaikan dan ringkasan masa hadapan dalam aplikasi DDD.

1. Cabaran yang dihadapi

Cabaran 1: Kerumitan logik perniagaan yang tinggi. Dengan akses pelbagai perkhidmatan, logik baharu sentiasa ditambah untuk menghadapi perkhidmatan tertentu dalam senario yang berbeza.

Contohnya: logik pengecaman niat dalam proses.

Pengecaman niat memerlukan pengecaman berbilang model AI Niat yang diiktiraf oleh berbilang model mungkin bercanggah dan peraturan konfigurasi niat yang bercanggah perlu dipilih. Pada masa yang sama, untuk beberapa permulaan sejuk atau senario pengoptimuman kecemasan, adalah perlu untuk menyokong pengenalpastian niat dengan mengkonfigurasi peraturan untuk berkuat kuasa dalam masa nyata. Dan slot perkataan yang sepadan perlu disokong dalam pengecaman niat peraturan. Terdapat banyak jenis slot perkataan Global dengan senario dan slot perkataan dengan proses dibezakan dari segi keutamaan. Daripada sumber pengenalpastian data, ia boleh dibahagikan kepada yang dikenal pasti oleh AI, yang dipadankan dengan peraturan kamus atau yang diluluskan oleh pihak perniagaan. Selepas perniagaan dibangunkan untuk satu tempoh masa, atribut berbeza ditambahkan pada jenis slot yang berbeza Contohnya, slot untuk siri kereta termasuk produk, skop perniagaan, bukan operasi, dll.; 2: Struktur seni bina kod tidak jelas. Apabila keperluan perniagaan ditambah, saiz kod meningkat. Ditambah dengan kerumitan logik dan kod pembangun pasukan yang berbeza, pelbagai sempadan logik secara beransur-ansur menjadi mengelirukan.

Contohnya: Kaedah pembangunan biasa kami ialah membukanya mengikut modul berfungsi, dan proses perniagaan disambungkan secara bersiri untuk menyelaraskan setiap modul untuk melengkapkan keperluan perniagaan secara bersama. Walau bagaimanapun, apabila berurusan dengan logik kompleks jenis perniagaan ini, reka bentuk penyelesaian ini mempunyai kelemahan yang besar, dan sempadan modul mudah ditembusi.

Hubungan antara modul memanggil satu sama lain Reka bentuk pengasingan asal modul sebenarnya telah rosak sepenuhnya semasa proses pelaksanaan. Modul terbelah menegak yang asalnya ideal menjadi struktur seperti mesh.

Atribut atau kaedah yang dibangunkan oleh ketua modul di peringkat pertengahan adalah bergantung kepada modul luaran yang lain, menyebabkan fungsi menjadi berbeza. Ini membawa kepada peningkatan risiko apabila keperluan berubah kemudian, atau mungkin didapati bahawa kaedah yang boleh diubah sesuka hati tidak boleh diubah, dan kod logik tambahan perlu ditambah untuk melaksanakannya. Ini menjadikan kod yang sudah kompleks menjadi lebih kompleks.

Pembubaran keperluan perniagaan adalah tidak munasabah Fungsi yang diperlukan dibangunkan berdekatan apabila dilaksanakan, dan pembongkaran modul tidak diikuti dengan ketat, dan terdapat kekurangan pemikiran bersatu sebagai panduan.

Cabaran 3: Terdapat begitu banyak permintaan untuk produk sehingga sukar untuk mengetahui sama ada ia mempunyai nilai sebenar.

Cabaran 4: Logik berubah dengan pantas, dan banyak tuntutan memerlukan reka bentuk semula logik kod.

Cabaran 5: Terdapat banyak perniagaan, penerangan yang tidak konsisten bagi setiap perniagaan dan kos komunikasi yang tinggi.

Sempadan menegak dipecahkan, kerumitan kod meningkat dan proses perniagaan sering dilaraskan. Dimensi berbilang ini ditindih antara satu sama lain, menjadikan pembangunan dan penyelenggaraan secara eksponen lebih sukar. Kestabilan sistem aplikasi peringkat pertama robot telefon sukar untuk dijamin. Walaupun rakan sekelas teknikal semuanya jurutera kanan, mereka telah mereka bentuk mengikut idea perkhidmatan mikro yang mereka boleh fahami dan membongkar projek mengikut modul Walaupun logik kod telah memetik banyak corak reka bentuk untuk dibina dan dikembangkan, walaupun ia telah disambungkan ke pelbagai bahagian syarikat, alat kualiti Platform, menulis banyak ujian unit. Walau bagaimanapun, apabila keperluan baru projek itu diulang, banyak "kejutan" masih muncul, menyebabkan sakit kepala untuk seluruh pasukan.

2. Kenapa DDD

Kenapa DDD? Terdapat begitu banyak tindanan teknologi dan begitu banyak idea setiap hari, mengapa DDD digunakan untuk menanganinya? Pertama sekali, DDD mengubah suai "cara menangani kerumitan teras perisian" dengan sangat baik, yang membuatkan ramai orang ingin mengetahuinya. Jadi mari kita lihat cara DDD menyelesaikan cabaran yang dihadapi dalam projek.

Pertama sekali, mari kita lihat klasifikasi kerumitan DDD dan tentukan sama ada kerumitan yang perlu dihadapi oleh DDD ialah cabaran yang saya hadapi. Dalam bahan berkaitan DDD, punca kerumitan diterokai dan dianalisis daripada dua dimensi keupayaan memahami dan keupayaan ramalan.

Keupayaan memahami (iaitu sistem perisian adalah kompleks dan sukar untuk difahami oleh pembangun):

Skala pertama: Faktor pertama yang mempengaruhi keupayaan pemahaman. Terdapat ratusan juta baris kod, dan hubungan antara setiap titik permintaan mempengaruhi satu sama lain. Mengubah suai satu kawasan akan menjejaskan seluruh badan.

Struktur kedua: Struktur yang tidak munasabah atau mengelirukan, menyukarkan pembangun untuk mengekalkan fungsi.

Keupayaan ramalan (iaitu, pembangunan perniagaan sukar untuk diramalkan):

Apabila keperluan berubah, sukar untuk meramalkan hala tuju pelaksanaan perisian, dan masalah reka bentuk yang berlebihan dan kurang- reka bentuk akan berlaku. Lebih reka bentuk, banyak antara muka telah dikhaskan, dan banyak corak telah dibina untuk meningkatkan kerumitan pelaksanaan kod, tetapi kemudiannya didapati bahawa ia tidak digunakan. Reka bentuk tidak mencukupi, dan realisasi keperluan tidak mengambil kira pembangunan kemudian Apabila perubahan berlaku, reka bentuk sedia ada perlu dibatalkan dan dibangunkan semula.

Punca kerumitan yang disebabkan oleh DDD diringkaskan sebagai: skala, struktur dan perubahan; skala dan struktur mencipta halangan kepada pemahaman, perubahan mewujudkan halangan kepada ramalan, dan kedua-duanya membentuk masalah kerumitan.

Kedua, DDD bukan sekadar teori fasa reka bentuk kod, tetapi juga termasuk panduan reka bentuk proses penuh daripada analisis keperluan, pemetaan seni bina, pemodelan dan pelaksanaan.

Dalam peringkat analisis permintaan, nilai perniagaan diketahui dengan tepat lebih awal melalui ideologi panduan yang relevan dan hala tuju perubahan masa depan ditangkap. Dalam peringkat pemetaan seni bina, ideologi panduan proses daripada keperluan kepada seni bina diberikan, dan berat reka bentuk serta spesifikasi ditambah. Melalui pemisahan sub-domain, pelapisan sistem dan klasifikasi perniagaan konteks terhad, spesifikasi panduan disediakan untuk memastikan kejelasan seni bina sistem dan mengurangkan kerumitan sistem. Dalam peringkat pemodelan dan pelaksanaan, model meta berkaitan reka bentuk dipacu domain diberikan untuk menjelaskan pembahagian fungsi setiap bahagian dan bertindak balas dengan cepat kepada keperluan perniagaan dan perubahan fungsi masa hadapan.

Sekali lagi, mari kita lihat ideologi panduan yang diberikan oleh DDD:

Isu skala: pecah sempadan. Bahagikan dan takluki pembongkaran dengan subdomain dan konteks terhad.

Memandangkan idea pecah dan takluk, DDD memberikan dua meta-model reka bentuk yang penting: konteks bersempadan dan pemetaan konteks.

Isu struktur: seni bina berlapis + pengasingan terhad.

Lapisan berfungsi untuk mengasingkan logik perniagaan dan isu kerumitan pelaksanaan teknikal. Seni bina berlapis yang diperkenalkan oleh DDD merangkum logik perniagaan ke dalam lapisan domain dan meletakkan pelaksanaan teknikal yang menyokong logik perniagaan ke dalam lapisan infrastruktur. Lapisan aplikasi di atas lapisan domain merangkum perkhidmatan aplikasi dan melekatkan kedua-duanya untuk kerjasama.

Isu tukar: Reka bentuk perubahan secara proaktif.

Perubahan tidak boleh dikawal, hanya perubahan yang boleh diterima. Dalam peringkat analisis permintaan, pemikiran 5W digunakan untuk mengenal pasti corak perubahan dan mengawal perubahan perniagaan. DDD menggunakan metamodel reka bentuk dipacu model untuk memodelkan domain konteks terikat, membentuk model domain yang menggabungkan analisis, reka bentuk dan pelaksanaan.

Akhir sekali, mari kita lihat penyelesaian yang diberikan oleh DDD. Ia memperkenalkan satu set model meta reka bentuk yang diperhalusi menjadi corak, membolehkan perisian perniagaan mengawal skala, memisahkan struktur dan bertindak balas secara proaktif kepada perubahan.

Izinkan saya memperkenalkan secara ringkas gambar ini, yang terbahagi kepada dua bahagian. Bahagian pertama ialah bahagian yang dibulatkan dengan titik di bawah dan tidak melibatkan pelaksanaan teknikal tertentu. Beberapa penyelesaian model meta untuk menangani ruang masalah dijalankan dalam peringkat analisis keperluan. Di bahagian lain, berdasarkan bahagian pertama, kami akan melakukan pelapisan seni bina sistem khusus, pengabstrakan dan pengagregatan objek, dan pembongkaran perkhidmatan Pada peringkat ini, kami akan melaksanakan reka bentuk yang sepadan.

Pemahaman saya ialah ini metamodel reka bentuk ini menyediakan penyelesaian lengkap daripada analisis permintaan, reka bentuk dan pelaksanaan. Pembongkaran sistem dalam peringkat analisis keperluan (sepadan dengan model meta sub-domain dalam rajah). Kemudian bahagikannya ke dalam konteks sempadan butiran kemas kini. Dan skema hubungan kolaboratif setiap sempadan diberikan (sepadan dengan model meta pemetaan konteks dalam rajah). Fasa pelaksanaan reka bentuk menyediakan pelan elemen reka bentuk reka bentuk dipacu model, melalui reka bentuk berbutir bagi seni bina hierarki sistem, perkhidmatan domain, pengagregatan, dsb. Menyediakan satu set penyelesaian yang lengkap, disokong secara teori, boleh dilaksanakan dan standard.

Analisis DDD di atas dan kedudukan kerumitan masalah adalah titik kesakitan sepenuhnya dalam sistem robot telefon. Penyelesaian yang diberikan juga menyelesaikan pelbagai cabaran yang dihadapi oleh perniagaan dengan sempurna. Selepas menyedari nilainya, pasukan dengan cepat mencapai kata sepakat untuk melaksanakannya dalam projek seterusnya.

3. Langkah pelaksanaan DDD

Saya tidak akan menerangkan secara terperinci tentang butiran meta-model dan sempadan perniagaan, tetapi secara langsung memberikan langkah dan produk sebenar pasukan kami.

3.1 Langkah pertama peringkat pra-penyelidikan

Pengalaman kami dalam bahagian ini ialah seseorang dalam pasukan bertindak sebagai pendahulu, mula-mula menghabiskan tenaga untuk kajian mendalam tentang konsep berkaitan DDD, dan kemudian menyegerakkannya kepada seluruh pasukan. Setakat pasukan kami, fasa penyelidikan adalah berpecah-belah dan sukar untuk menganggarkan tempoh masa yang diperlukan Fasa popularisasi sains pasukan berlangsung 4 kali dan mengambil masa 8 jam. Selepas itu, pelajar dalam pasukan mempunyai keupayaan untuk belajar dengan cepat dan mendalam berdasarkan bimbingan konsep. Dan aturkan ahli pasukan untuk berbincang antara satu sama lain untuk mengesahkan pemahaman.

3.2 Langkah kedua memperkenalkan ideologi panduan dan spesifikasi pelaksanaan

3.2.1 Memperkenalkan sokongan teori model 5W dalam peringkat analisis permintaan boleh membantu mengenal pasti keperluan sebenar dan mengawal secara proaktif arah perubahan dan Menghapuskan keperluan yang tidak bermakna.

Bahagian ini ialah teori 5W sebagai sokongan teori untuk menganalisis keperluan produk Ia sangat membantu untuk mengenal pasti keperluan sebenar dan menganalisis hala tuju pembangunan perniagaan dengan lebih baik. Keperluan tidak sah juga boleh dikurangkan daripada sumber, seperti ditunjukkan dalam rajah di atas;

3.2.2 Memperkenalkan spesifikasi perkhidmatan dan melaksanakan fungsi perniagaan kod berasaskan dokumen. Ia berguna untuk pembangunan dan pengisihan keperluan seterusnya, dan juga boleh digunakan sebagai pertimbangan untuk liputan ujian unit.

• 3.2.2.1 Ahli pasukan bersetuju bahawa spesifikasi perkhidmatan perlu ditulis terlebih dahulu dan kemudian dibangunkan. Masa yang dihabiskan untuk menulis spesifikasi perkhidmatan sebenarnya adalah soal menyusun pemahaman teknikal tentang keperluan dan menjelaskan idea-idea bahagian masa ini boleh diperoleh kembali semasa menulis kod nanti.
• 3.2.2.2 Spesifikasi perkhidmatan dan keperluan Spesifikasi perkhidmatan sepadan dengan ujian tunggal. Dengan cara ini, ia menyelesaikan masalah yang tidak ada standard untuk ujian tunggal sebelum ini (liputan kod dan kaedah yang saya faham tidak boleh dipanggil standard).

Berikut ialah templat spesifikasi perkhidmatan yang diterima pakai oleh pasukan kami:

Nombor: Nombor unik yang menandakan perkhidmatan perniagaan.

Nama: Nama perkhidmatan perniagaan dalam bentuk frasa kata kerja.

Penerangan:

sebagai

saya mahu

supaya

mencetuskan acara:

Acara perkhidmatan perniagaan yang dicetuskan secara aktif oleh peranan boleh menjadi satu klik pada kawalan UI, strategi khusus atau mesej yang dihantar oleh sistem pendamping, dsb.

Proses asas:

digunakan untuk menyatakan proses utama perkhidmatan perniagaan, iaitu, senario perniagaan pelaksanaan yang berjaya. Ia juga boleh dipanggil "senario kejayaan utama".

Proses alternatif:

Proses lanjutan yang digunakan untuk mewakili perkhidmatan perniagaan, iaitu, senario perniagaan di mana pelaksanaan gagal.

Kriteria penerimaan:

Siri syarat atau peraturan perniagaan yang boleh diterima, disenaraikan dalam titik tumpu.

3.3 Langkah ketiga ialah menentukan penyelesaian seni bina

Ketahui penyelesaian metamodel reka bentuk dipacu model dalam DDD. Tujuan utama adalah untuk membahagikan sempadan tanggungjawab, iaitu konteks terikat, untuk menukar hubungan struktur rangkaian tradisional kepada hubungan segmentasi menegak dan mengurangkan pergantungan bersama. Penggunaan keseluruhan pembongkaran teks dalam talian terhad dan reka bentuk pemacu berlian membentuk panduan ideologi keseluruhan. Sistem ini mengguna pakai seni bina berlapis COLA 4.0

3.4 Langkah keempat ialah membentuk standard penamaan konsensus untuk membentuk spesifikasi pengekodan pasukan

Konsensus mengenai penamaan pakej , penamaan kelas, masuk dan keluar dalam kontrak mesej Rujukan pasukan dan spesifikasi lain. Apa yang saya ingin katakan di sini ialah tiada standard rujukan. Saya harap semua orang mula-mula dapat memahami idea DDD, dan kemudian merujuk kepada skema penamaan dengan konsensus yang tinggi dalam industri. Pada masa yang sama, anda perlu mengambil kira pilihan gaya pengaturcaraan ahli pasukan, dan akhirnya merumuskan piawaian pengekodan pasukan anda sendiri.

Ambil penamaan mesej input dan output kami sebagai contoh. Selepas mempertimbangkan semua pihak, kami tidak mengguna pakai kaedah penamaan terperinci yang ditunjukkan di atas. Sebaliknya, konsensus mudah dalam pasukan ialah parameter input *permintaan, parameter output *membalas standard penamaan.

3.5 Langkah kelima ialah mengenal pasti konteks terhad berdasarkan ciri-ciri perniagaan

Berdasarkan idea DDD, jalankan peristiwa menyerbu perniagaan, jalankan analisis permintaan global dan reka bentuk pemetaan seni bina di bawah bimbingan bahasa bersatu, dan kenal pasti Konteks terhad perniagaan.

Pelajar teknikal mereka bentuknya berdasarkan perniagaan mereka sendiri agak mudah untuk mencarinya dengan merujuk kepada maklumat Demo, jadi saya tidak akan menerangkan butirannya di sini. Berikut ialah proses panduan untuk mengenal pasti konteks sempadan, proses pemetaan berbentuk V.

3.6 Akhirnya memasuki peringkat pelaksanaan pemodelan

Adalah disyorkan untuk menggunakan pembangunan dipacu ujian untuk pengekodan, iaitu, menggunakan merah, hijau dan kuning pemandu;

Kaedah ini mengikut tiga undang-undangnya, yang boleh memperbaiki masalah kekurangan reka bentuk dan lebihan reka bentuk keperluan.

定律一	一次只写一个刚好失败的测试，作为新加功能的描述。
定律二	不写任何产品代码，除非它刚好能让失败的测试通过。
定律三	只在测试全部通过的前提下做代码重构，或开始新加功能。

4. Penambahbaikan kepada pasukan

4.1 Daripada menerima permintaan secara pasif kepada bertindak balas secara aktif

Dalam peringkat analisis permintaan, gunakan prinsip 5W. Menganalisis rasionaliti permintaan dan dapat mengawal perubahan arah projek secara proaktif. Selesaikan "Cabaran Tiga" untuk mengenal pasti nilai permintaan dan perbaiki "Cabaran Empat" untuk mengawal arah perubahan pembangunan perniagaan.

4.2 Mengurangkan kos komunikasi

Gunakan bahasa bersatu dan komunikasi ideologi untuk mengurangkan kos kerjasama dalam semua aspek "Cabaran Lima".

4.3 Penambahbaikan reka bentuk seni bina

Buka saiz kod secara munasabah dengan mereka bentuk model subdomain dan konteks terhad model meta. Melalui pemikiran berlapis DDD, kerumitan logik perniagaan dan dimensi teknikal diasingkan, dan struktur kod adalah jelas. Pada masa yang sama, projek itu menggunakan struktur simetri berbentuk berlian dan berinteraksi dengan bahagian luar melalui pintu masuk utara-selatan untuk mengelakkan berlakunya rangkaian modul. Menyelesaikan masalah "Cabaran 2" dan mengurangkan kerumitan "Cabaran 1".

4.4 Penambahbaikan Pelaksanaan Teknikal

Apabila membangunkan fungsi perniagaan, pasukan akan mempertimbangkan had keperluan yang munasabah. Semasa proses pelaksanaan, kami akan mempertimbangkan sama ada untuk meletakkannya dalam lapisan domain atau lapisan perkhidmatan perniagaan, dan sama ada untuk menggunakan model anemia atau model kesesakan untuk melaksanakan fungsi.

4.5 Penambahbaikan spesifikasi dokumen

Dari segi spesifikasi dokumen, mekanisme spesifikasi perkhidmatan diperkenalkan. Ia boleh digunakan sebagai alat untuk menyelesaikan keperluan dan sebagai asas untuk ujian tunggal. Pada masa yang sama, dokumen penerangan perkhidmatan juga disediakan untuk kegunaan kemudian.

4.6 Penambahbaikan Pelaksanaan Kod

Dari segi pelaksanaan kod, daripada seni bina kepada pelaksanaan pengekodan dan penamaan, satu set spesifikasi bertanda telah dibentuk.

Secara umumnya, cara pemikiran pasukan telah berubah di bawah mod ini. Dengan menggunakan pelbagai model meta, kami boleh menghadapi cabaran yang dibawa oleh aspek berbeza daripada analisis permintaan kepada seni bina sistem dan pelaksanaan kod.

5. Konflik yang dihadapi dari teori ke amalan

5.1 Model anemia PK model kesesakan

Model anemia: Dari segi orang awam, ia adalah objek domain yang hanya mempunyai getter/setter kaedah untuk atribut. Kelas data tulen, logik perniagaan dan logik aplikasi semuanya diletakkan dalam lapisan perkhidmatan Objek domain di bawah model ini dipanggil "objek domain anemia" oleh Martin Fowler.

Model kesesakan: Sebaliknya, model kesesakan bukan sahaja mengandungi sifat objek, tetapi juga kelakuan objek, termasuk logik perniagaan.

Dari perspektif berorientasikan objek, objek mengandungi atribut dan gelagat, jadi model kesesakan harus digunakan, dan DDD juga mengesyorkan menggunakan model kesesakan pada dasarnya. Tetapi apabila ia datang kepada status pembangunan khusus, walaupun model anemia mempunyai banyak masalah, ia telah berada dalam industri selama bertahun-tahun dan begitu biasa digunakan, dan ia masih mempunyai nilainya. Di samping itu, kebanyakan aplikasi JAVA menggunakan tindanan teknologi Mybatis, dan banyak objek adalah entiti anemia yang dijana secara automatik oleh pemalam. Jadi persoalannya, menggunakan model hiperemia bermakna meninggalkan beberapa alat yang mudah. Terdapat perbezaan besar dalam pasukan mengenai isu ini. Pada akhirnya, pendekatan kami ialah tiada standard keras untuk bahagian ini, tetapi disyorkan untuk menggunakan mod kesesakan.

5.2 Mematuhi kekangan penukaran data dengan tegas

PK diperkemas dan penggunaan data luaran yang cekap secara langsung

Dalam idea DDD, untuk memastikan kebolehpercayaan perkhidmatan domain . Data yang perkhidmatan domain bergantung kepada diperlukan untuk menjadi entiti dan data agregat dalam domain dan penggunaan terus data kontrak mesej luaran tidak dibenarkan. Penukaran data yang diperoleh daripada pintu masuk utara-selatan yang sepadan dengan seni bina simetri berlian akan membawa beban kerja tambahan. Sesetengah ahli pasukan mencadangkan bahawa struktur tertentu yang agak stabil tidak perlu mematuhi prinsip ini Sebabnya ialah ia boleh meningkatkan kelajuan pembangunan, dan mereka percaya bahawa 90% daripada data mungkin sumber dengan struktur yang agak stabil seperti pangkalan data. Tetapi pada akhirnya, pasukan itu masih dikehendaki mematuhi ideologi panduan ini.

5.3 Pemprosesan cache membenarkan pengasingan sempadan PK dikongsi

Pemprosesan cache dalam sempadan berbeza sistem yang sama: membenarkan pengasingan sempadan PK dikongsi.

Berdasarkan senario pada masa itu, membenarkan perkongsian boleh mengurangkan sedikit beban kerja dan menjimatkan sumber dalam jangka pendek. Tetapi sebab mengapa kita perlu membuat sempadan adalah untuk memutuskan hubungan dan mengelakkannya daripada menjadi terlalu besar. Cadangan yang diberikan di sini adalah untuk mempertimbangkan terlebih dahulu sama ada munasabah untuk menggabungkan perkhidmatan yang berkongsi data ke dalam satu sempadan. Jika penggabungan tidak dapat dilakukan, data mesti diasingkan.

5.4 Spesifikasi perkhidmatan membandingkan keperluan PK bahagian hadapan dan bahagian belakang

Idea teori panduan adalah sangat cantik, dan ia diperlukan untuk melindungi pemikiran pelaksanaan teknologi semasa analisis permintaan. Tetapi selepas semua, ia perlu dilaksanakan dalam timbunan teknologi Apabila ia datang kepada pelaksanaan teknologi, ia akan diganggu oleh pelaksanaan teknologi. Isu yang menonjol pada masa itu ialah pelaksanaan fungsi boleh diletakkan di bahagian hadapan atau dilaksanakan sebagai perkhidmatan bahagian belakang.

Contoh 1: Keperluan memerlukan paparan gabungan "id + nama", tetapi dua medan id dan nama yang dikembalikan oleh antara muka hujung belakang digabungkan dengan susunan teknologi bahagian hadapan sebenar dan spesifikasi perkhidmatan untuk bahagian hadapan dan bahagian belakang adalah tidak konsisten.

Contoh 2: Keperluan memerlukan pengesahan bahawa parameter tidak kosong. Dalam sesetengah sistem dalaman, pasukan teknikal pasukan kami terdiri daripada jurutera susun penuh hadapan dan belakang, yang membahagikan kerja dan membangunkan modul mengikut keperluan. Selalunya mereka tidak begitu ketat untuk mengesahkan kedua-dua hujungnya. Ia juga membawa kepada konflik di mana penghujung spesifikasi perkhidmatan berorientasikan.

Pilihan terakhir kami: pasukan menggunakan lapisan perkhidmatan bahagian belakang. Tetapi pada masa yang sama, kami akan membuat beberapa penambahbaikan, seperti mengalihkan pengesahan dan fungsi lain ke tahap antara muka.

5.5 Siapakah yang akan memastikan bahawa spesifikasi perkhidmatan ditulis dengan betul Teknologi PK Produk

Keadaan ideal pada peringkat awal adalah untuk disahkan oleh produk sisi permintaan, berdasarkan prinsip sesiapa yang memerlukannya mengesahkannya? ia. Walau bagaimanapun, disebabkan perbezaan dalam 4.4, pelaksanaan sebenar kami disemak oleh orang teknikal yang bertanggungjawab.

6. Penambahbaikan dan ringkasan masa hadapan dalam aplikasi DDD

Pasukan kini telah melaksanakan aplikasi DDD dari perspektif seni bina dan spesifikasi. Tetapi beberapa butiran, seperti reka bentuk kelas agregat, entiti dan objek nilai, tidak begitu terperinci. Kami akan memajukan lagi penambahbaikan terperinci ini pada masa hadapan. Pada masa yang sama, beberapa projek lama yang digunakan akan diubah dan dibina semula mengikut idea DDD.

Sesetengah orang berpendapat bahawa penggunaan DDD akan mengurangkan kecekapan pembangunan Ini juga menjadi kebimbangan banyak pasukan. Ini adalah cara kita melihat masalah ini Senario menggunakan DDD adalah untuk menyelesaikan masalah perniagaan yang kompleks, yang sememangnya akan meningkatkan jumlah kod. Tetapi ia tidak bermakna mengurangkan kecekapan pembangunan. Struktur seni bina yang jelas, perkhidmatan domain agregat dan piawaian piawai akan membawa faedah kepada peningkatan permintaan kemudian, penyelenggaraan kod dan kawalan kerumitan yang jauh melebihi pelaburan. Selain itu, menurut data yang diberikan oleh industri perisian, 80% masa dihabiskan untuk analisis dan reka bentuk permintaan, manakala masa pembangunan hanya menyumbang 20%. Oleh itu bahagian kerugian ini bukan tumpuan.

Akhir sekali, huraikan pengalaman anda menggunakan DDD. Terdapat banyak jenis model meta DDD, dan semua orang boleh mempelajari dan mengguna pakainya secara sengaja berdasarkan titik kesakitan yang dihadapi oleh perniagaan. Dalam persekitaran perniagaan sebenar, model domain kami mempunyai lebih kurang "kepakaran". Jika 100% mematuhi spesifikasi DDD, kosnya mungkin agak tinggi, jadi perkara yang paling penting ialah memahami idea DDD dan membuat pilihan terakhir Penyelesaian yang sesuai dengan perniagaan anda.

Mengenai pengarang

Li Xiaohua

• Jabatan Perniagaan Peniaga - Jabatan Teknologi Peniaga.
• Menyertai Autohome pada 2016 dan kini bekerja dalam pasukan seni bina data peniaga, yang bertanggungjawab untuk projek robot telefon.

Atas ialah kandungan terperinci Latihan DDD untuk pasukan robot telefon. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!