Acara domain

Apakah itu acara domain

Acara domain ialah mekanisme penyahgandingan yang membolehkan ciri berkomunikasi tanpa kebergantungan langsung. Daripada ciri A memanggil ciri B, ciri A menerbitkan satu acara dan ciri B melanggannya.

DomainEventBus ialah bas terbit/langgan siaran dalam proses. Penerbit memanggil publish(event); pelanggan menggunakan strim on<T>() yang bertaip. Setiap acara melaksanakan DomainEvent dan membawa occurredAt.

Bas ini berjalan dalam cc_server. Setiap penerbit dan setiap pelanggan yang hidup berada di situ. Tiada klien melihat bas ini. Apa yang klien lihat ialah subset terpilih yang dipancarkan semula oleh pelayan sebagai bingkai JSON-RPC notifications/*.

Mengapa perlu ada bas

Tanpa acara, setiap reaksi antara ciri ialah satu import. Laluan pemberitahuan terpaksa mengimport ciri ejen, ciri pull request, penetikan dan mesyuarat semata-mata untuk tahu bila perlu memaparkan toast — dan setiap satu daripadanya kemudiannya terpaksa tahu bahawa pemberitahuan wujud. Penetikan pula terpaksa mengimport pipeline supaya tiket yang selesai boleh memajukan satu larian. Graf kebergantungan menjadi kusut, dan kernel yang dikongsi berhenti dikongsi.

Menerbitkan acara memecahkan gelung itu. Laluan pemberitahuan melanggan dua puluh satu kelas acara dan tidak mengimport mana-mana ciri yang membangkitkannya. Penghantar pencetus pipeline melanggan seluruh bas dan tidak tahu apa-apa tentang pull request, tiket atau mesyuarat. Kebolehcerapan mengagregatkan hasil larian tanpa menyentuh penghantaran.

Kosnya yang biasa: penerbit tidak dapat tahu sama ada ada orang mendengar, dan pendengar yang tidak pernah dibina akan kekal lengai secara senyap. TicketRemoteSyncHandler ialah contoh yang kekal: ia diisytiharkan, dilindungi ujian, dan tidak pernah disambungkan dalam pengeluaran.

Apa yang bas ini bukan

Ada satu perkara yang bas ini tidak miliki, dan elok kita jelaskan dengan tepat.

Jejak audit bukan unjuran strim acara. Setiap operasi RPC yang mengubah keadaan diaudit secara lalai — RepoOp.audited lalai kepada true dan sesuatu operasi hanya menarik diri dengan mengisytiharkan audited: false, tindakan sengaja yang kelihatan pada operasi itu sendiri. Penghantar menambahkan baris “siapa buat apa, dari mana” terus selepas panggilan yang berjaya. Tiada DomainEventAuditBridge. ActivityLogPersister menulis baris activity_log daripada acara ActivityLogged; itu suapan yang berasingan daripada audit RPC.

Bas acara ialah pengangkutan untuk pemberitahuan dan automasi. Ia bukan sistem rekod simpan kira.

Apa yang bas ini memang pacu

• Pemberitahuan. Dua puluh satu kelas acara ditukar oleh pelayan menjadi bingkai notifications/*, direkodkan ke dalam suapan kekal bagi setiap ruang kerja dan disiarkan kepada sesi yang bersambung. Bingkai yang workspace_id-nya menamakan ruang kerja yang pengguna sesi bukan ahlinya digugurkan di pelayan; klien kemudian menapis bakinya kepada ruang kerja yang sedang dilihatnya.
• Automasi dipacu acara. Pencetus pipeline melanggan bas dan memulakan pipeline yang sepadan secara automatik (lihat di bawah).
• Reaksi kitaran hayat. Mencipta ruang kerja menyemai ejen CEO dan spesialisnya, templat pipeline terbina dalam, serta suite eval permulaan. Larian ejen yang selesai menyambung semula langkah pipeline yang digantung, menutup tugas, menyuap penyelia matlamat, boleh mengejutkan pemeriksa bernama, dan boleh mencetuskan semula ketua pasukan. PR yang dicantumkan atau ruang yang dipadam mencetuskan pengumpulan sampah worktree.
• Penyegerakan merentas vendor. Perubahan tiket tempatan ditolak keluar kepada vendor yang dikonfigurasikan oleh penyelaras yang mendengar lima acara tiket.

Kategori acara

Acara merangkumi seluruh permukaan produk. Secara ringkasnya:

• Ruang kerja, ejen dan repo — penciptaan ruang kerja, penyempurnaan larian, pendaftaran repo, kemas kini kemahiran
• Pull request — penerbitan, perubahan status, cantuman, permintaan semakan, sebutan, pemantauan PR yang ditulis sendiri, PR yang dikesan secara luaran
• Pemesejan — mesej, ruang dan kemajuan penyediaan ruang
• Tiket — cipta, tugaskan, tugaskan semula, butiran, status dan tiga hasil akhir
• Tugas — bingkai kitaran hayat berjujukan untuk satu larian yang dihantar, supaya klien boleh menyusun dan menyahpenduanya
• Pipeline — acara larian akhir sahaja (selesai, dibatalkan, gagal)
• Kebolehcerapan — entri log aktiviti dan ambang belanjawan
• Identiti dan keahlian — ahli ditambah, dibuang, peranan diubah
• Kalendar dan mesyuarat — tamat tempoh pengesahan, mesyuarat bermula dan rakaman selesai
• Stesen — pengambilalihan, penuaian dan penutupan tidak dijangka

Memori, orkestrasi, dokumen pelan, artifak, kelulusan, pengambilan penyegerakan tiket, penyegaran kalendar, cantuman worktree, penciptaan pengguna, jemputan dan pembatalan peranti bukan acara domain; lihat rujukan.

Untuk katalog lengkap — kesemua 53 kelas acara konkrit, muatannya dan 24 pelanggan yang menggunakannya — lihat Rujukan acara domain. Halaman itu ialah inventori; halaman ini modelnya.

Kawalan akses langsung berjalan atas dua mekanisme berbeza

Acara keahlian dan peranti kelihatan simetri tetapi sebenarnya tidak, dan itu penting jika anda menaakul tentang betapa pantas sesuatu pembatalan berkuat kuasa.

Membatalkan peranti memang menamatkan sesinya. Pelayan memantau jadual peranti berganding dan menggugurkan mana-mana sesi hidup yang perantinya telah keluar dari set aktif, dalam beberapa saat.

Membuang ahli tidak menutup soket. WorkspaceMemberRemoved digunakan: LocalRpcServer dan RemoteRelayHost menggugurkan langganan ruang kerja yang dilampirkan oleh pengguna itu, dan RemoteEventForwarder membatalkan kesahihan cache keahliannya supaya bingkai seterusnya untuk ruang kerja itu tidak ditolak. Yang menafikan RPC berikutnya masih gate peranan, yang menyelesaikan semula keahlian pada setiap panggilan — jadi permintaan mereka yang seterusnya ditolak dengan “Not a member of this workspace”. Kesannya serta-merta untuk apa sahaja yang mereka cuba lakukan; ia cuma tidak dicapai dengan menamatkan talian terhadap mereka.

Pencetus pipeline

Pencetus pipeline melanggan acara domain dan memulakan pipeline yang sepadan secara automatik. PipelineTriggerDispatcher mendengar seluruh bas, kemudian:

1. Memintas lebih awal melainkan jenis acara itu salah satu yang dapat dipetakannya kepada muatan
2. Mencari pencetus yang didayakan yang sepadan dengan jenis acara itu, merentas setiap ruang kerja
3. Menapis setiap satu mengikut ruang kerjanya sendiri dan menggunakan penapis padanan muatannya
4. Memulakan satu larian bagi setiap pencetus yang terselamat

Kekangan pentingnya ialah langkah 1. Bas membawa 53 jenis acara; pemilih tambah pencetus memulakan larian untuk empat belas ini (cabang muatan EventPayloadMapper): ExternalPrDetected, PullRequestPublished, PullRequestStatusChanged, PrMerged, MessageReceived, TicketAssigned, TicketCompleted, TicketFailed, TicketCancelled, BudgetThresholdCrossed, RepoAdded, MeetingRecordingStopped, SkillUpdated dan SpaceDeleted. Tiada apa-apa yang lain boleh memulakan pipeline.

Bagaimana klien melihat semua ini

RemoteEventForwarder menterjemah acara kelas pemberitahuan menjadi bingkai dan menolaknya melalui RPC kepada sesi yang bersambung, di mana pemeta bingkai menukarnya menjadi pemberitahuan dalam aplikasi. Klien nipis oleh itu melihat unjuran strim acara pelayan tanpa memiliki sebarang pelaksanaan — itulah inti pemisahan klien nipis.

Namun bukan setiap bingkai yang ditolak itu pemberitahuan. Strim kitaran hayat tugas dan penugasan semula tiket dihantar secara langsung untuk memacu UI, tetapi ia tidak direkodkan ke dalam suapan pemberitahuan dan tidak memaparkan toast.

Lihat juga

• Pipeline dan automasi: apa yang dimulakan oleh pencetus
• Tiket dan perwakilan: penugasan kepada ejen berbanding pasukan
• Seni bina: bagaimana acara memenuhi peraturan kebergantungan
• Rujukan acara domain: katalog lengkap dan pelanggannya
• Sediakan pencetus pipeline
• Konfigurasikan pemberitahuan