Memahami Domain dan Membina Pasukan: Asas Perubahan (II)

Memulakan projek yang kompleks memerlukan pengumpulan konteks yang komprehensif sambil menghampiri pengetahuan domain secara serentak daripada perspektif baharu, memanfaatkan cerapan pakar domain. Pendekatan ini menjajarkan pasukan teknikal dengan objektif perniagaan dan mewujudkan peta jalan asas untuk membuat keputusan termaklum sepanjang kitaran hayat produk.

Sesi pengumpulan pengetahuan awal dengan pasukan terdahulu dan pengguna aplikasi semasa terbukti tidak produktif. Kami mempertimbangkan secara ringkas untuk meneruskan secara bebas, walaupun terdapat risiko yang wujud.

EventStorming: Membongkar Domain

Sebagai peneraju teknologi, saya memperjuangkan pendekatan dipacu domain sejak awal, memandangkan kerumitan projek dan keperluan pasukan untuk pemilikan. Ini memusatkan domain, memupuk pemahaman bersama (bahasa yang ada di mana-mana) yang memperkemas komunikasi dan memudahkan pemetaan keadaan semasa aplikasi.

Kami memulakan sesi EventStorming menggunakan templat Miro, menyediakan struktur dan legenda untuk fokus yang berkesan. Kebiasaan terlebih dahulu dengan konsep EventStorming, sama ada melalui penyediaan pra-sesi atau penjelasan awal, adalah sangat berfaedah.

Proses EventStorming berstruktur kami terdiri daripada:

1. Meneroka Acara Domain (Gambar Besar): Mengenal pasti, menyusun mengikut kronologi dan mengesahkan peristiwa sistem utama dengan pakar domain, menyerlahkan jurang dan kebergantungan.
2. Pemurnian dan Analisis: Menambah nota penerangan, mendokumentasikan soalan, menganalisis secara mendalam setiap peristiwa dan menentukan titik keputusan kritikal.
3. Pemodelan Domain: Mengenal pasti agregat dan sempadan, mentakrifkan pelakon dan peranan, mewujudkan arahan pencetus, mendokumentasikan dasar dan peraturan perniagaan serta mengenal pasti pencetus peristiwa dalaman/luaran.
4. Dokumentasi dan Pengesahan: Menyusun dan membersihkan maklumat yang dikumpul, mewujudkan hubungan yang jelas, mengesahkan model dengan pihak berkepentingan dan mencipta dokumentasi rujukan.

EventStorming menyediakan bukan sahaja pemahaman domain tetapi juga asas untuk menerapkan prinsip Reka Bentuk Dipacu Domain (DDD) secara strategik dan taktikal.

Reka Bentuk Dipacu Domain Strategik

Langkah awal yang penting melibatkan penstrukturan domain secara strategik. Kerumitan sistem dan keperluan untuk penjajaran teknikal/perniagaan membawa kepada penggunaan prinsip DDD. Pemetaan Konteks terbukti tidak ternilai, walaupun dalam monolit kami menunggu pemfaktoran semula. Kami mengenal pasti Konteks Terhad, beroperasi dalam konteks teknikal tunggal dengan kernel dikongsi. Analisis ini, walaupun tidak diterokai secara mendalam, membimbing projek ke arah seni bina berorientasikan domain, meningkatkan kedua-dua pembangunan teknikal dan kerjasama merentas pasukan.

Menentukan Sempadan (Konteks Sempadan)

Mengenal pasti Konteks Terhad menjelaskan perhubungan antara sistem dan sistem luaran, memudahkan kerumitan dan mewujudkan asas untuk modularisasi masa hadapan. Keputusan awal ini akan membimbing penguraian monolit kepada komponen yang boleh diurus sejajar dengan konteks yang ditentukan. Ini juga memudahkan keutamaan dan pengenalpastian kawasan untuk dipermudahkan, penyahgandingan atau penyingkiran. Kami menumpukan pada pelaksanaan Lapisan Anti Rasuah (ACL) untuk interaksi sistem luaran, memelihara integriti sistem.

Lima konteks utama telah dikenal pasti:

• Pesan Tugasan
• Penjanaan Label
• Penyediaan Pesanan
• Integrasi E-dagang
• Penyediaan Pesanan Pukal

Keputusan ini memupuk seni bina yang mampan dan pembangunan yang sejajar dengan keperluan perniagaan.

Bahasa Ubiquitous

Mewujudkan bahasa yang mantap di mana-mana terbukti penting. Manfaat bahasa yang dikongsi, yang dicipta melalui kerjasama antara pakar domain dan pembangun, jauh melebihi usaha terjemahan atau salah tafsir. Sumber hidup ini menghubungkan pasukan teknikal dengan pakar domain, meningkatkan komunikasi, mengurangkan salah faham dan memastikan perwakilan domain yang tepat dalam kod. Ini memupuk penyelesaian teknikal yang cekap dan sejajar dengan perniagaan.

Reka Bentuk Dipacu Domain Taktikal

Mengikuti rangka kerja strategik, kami melaksanakan prinsip DDD taktikal untuk menstruktur kod, mencerminkan realiti domain dan memastikan kemampanan jangka panjang.

Entiti dan Objek Nilai

Memahami perbezaan antara Entiti dan Objek Nilai adalah penting.

Entiti

Entiti mempunyai identiti yang unik dan berterusan, walaupun dengan perubahan atribut. Contohnya termasuk:

• Pesan
• Produk
• Pembawa
• Beli
• Pelanggan

Objek Nilai

Objek Nilai kekurangan identiti individu; nilai mereka menentukan mereka. Atribut yang sama menandakan kesetaraan. Ia tidak boleh diubah dan sesuai untuk merangkum konsep yang muncul di seluruh domain. Contohnya termasuk:

• Rujukan Produk
• ProductEan13
• Rujukan Pesanan
• Harga
• Berat
• Nombor Penghantaran

Pendekatan ini mencipta kod yang lebih mudah difahami dan modular dengan tanggungjawab yang jelas.

Contoh Objek Nilai:

<code class="language-php"><?php
readonly class ProductEan13
{
    public string $value;

    public function __construct(string $value)
    {
        $pattern = '/^\d{13}$/';
        if (!preg_match($pattern, $value)) {
            throw new \Exception('Invalid product Ean13');
        }
        $this->value = $value;
    }
}</code>

Perkhidmatan

Perkhidmatan dikategorikan mengikut tujuan dan corak yang dilaksanakan.

Perkhidmatan Domain

Perkhidmatan Domain merangkumi logik perniagaan yang tidak sesuai dengan entiti atau nilai, beroperasi dengan ketat dalam peraturan domain tanpa pergantungan infrastruktur.

<code class="language-php"><?php
readonly class ProductEan13
{
    public string $value;

    public function __construct(string $value)
    {
        $pattern = '/^\d{13}$/';
        if (!preg_match($pattern, $value)) {
            throw new \Exception('Invalid product Ean13');
        }
        $this->value = $value;
    }
}</code>

Perkhidmatan Aplikasi

Perkhidmatan Aplikasi menyelaraskan operasi domain dengan interaksi luaran, memusatkan operasi kompleks dan memisahkan domain dan infrastruktur. Ini termasuk Kes Penggunaan, Pengendali Perintah dan Pengendali Acara.

Perkhidmatan Infrastruktur

Perkhidmatan Infrastruktur mengendalikan interaksi komponen luaran (pangkalan data, sistem fail, dll.), bertindak sebagai penyesuai untuk mengekalkan agnostikisme domain.

<code class="language-php"><?php
class CheapestCarrierGetter
{
    public function get(
        DeliveryOptionCarrierCollection $deliveryOptionCarriers,
        Weight $orderWeight,
        Country $country,
        PostalCode $postalCode,
        bool $isCashOnDelivery = false,
    ): Carrier {
        // Logic to get the cheapest carrier
    }
}</code>

Klasifikasi Perkhidmatan

Perkhidmatan dikelaskan mengikut fungsi dan corak reka bentuk yang berkaitan: Transformer, Pembina, Kilang, Penyampai, Pemberitahu, Pengesah dan Pelanggan.

Pemodelan domain awal ini, walaupun tidak lengkap dan berulang, memupuk penyertaan dan komitmen pasukan. Penambahbaikan dan penstrukturan semula telah dijangkakan.

Sumber DDD yang disyorkan:

• "Reka Bentuk Dipacu Domain: Menangani Kerumitan dalam Hati Perisian" oleh Eric Evans
• "Melaksanakan Reka Bentuk Dipacu Domain" oleh Vaughn Vernon
• "Reka Bentuk Dipacu Domain dalam PHP" oleh Carlos Buenosvinos, Christian Soronellas & Keyvan Akbary

Membina Pasukan: Peringkat Tuckman

Penggunaan DDD selari pembentukan pasukan, mengikuti peringkat Tuckman (Membentuk, Mengserbu, Mengatur, Berprestasi).

Membentuk

Ahli pasukan awal menyemak projek, mendokumentasikan operasi dan asas teknikal dan organisasi (proses, piawai, alatan).

Ribut

Perselisihan kecil membawa kepada penentuan gaya kerja, kaedah komunikasi dan proses membuat keputusan.

Mengamalkan

Perjanjian pasukan, standard pengekodan, proses pembangunan, had WIP, peraturan penggunaan, pengurusan hutang teknikal dan ADR telah diwujudkan.

Mempersembahkan

Rangka kerja yang telah ditetapkan membolehkan pembangunan produk yang cekap, mengutamakan inisiatif berharga dan memupuk budaya penambahbaikan berterusan.

Dokumentasi: Model Diátaxis

Dokumentasi telah diuruskan menggunakan Halaman GitLab dan Jekyll dengan tema Just the Docs, mengikut model Diátaxis: Tutorial, Panduan, Penjelasan dan Rujukan. Mengautomasikan dokumentasi menggunakan Katalog Acara dan AsyncAPI telah dirancang tetapi tidak dilaksanakan sepenuhnya.

Atas ialah kandungan terperinci Memahami Domain dan Membina Pasukan: Asas Perubahan (II). Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!