Pertama, saya ingin mengatakan bahwa ini sepertinya pertanyaan / area yang terabaikan, jadi jika pertanyaan ini perlu diperbaiki, bantu saya menjadikan ini pertanyaan besar yang dapat bermanfaat bagi orang lain! Saya mencari saran dan bantuan dari orang yang telah mengimplementasikan solusi yang memecahkan masalah ini, bukan hanya ide untuk dicoba.
Dalam pengalaman saya, ada dua sisi aplikasi - sisi "tugas", yang sebagian besar didorong oleh domain dan merupakan tempat pengguna berinteraksi secara kaya dengan model domain ("mesin" aplikasi) dan sisi pelaporan, tempat pengguna dapatkan data berdasarkan apa yang terjadi di sisi tugas.
Di sisi tugas, jelas bahwa aplikasi dengan model domain kaya harus memiliki logika bisnis dalam model domain dan database harus digunakan sebagian besar untuk kegigihan. Pemisahan keprihatinan, setiap buku ditulis tentang hal itu, kita tahu apa yang harus dilakukan, luar biasa.
Bagaimana dengan sisi pelaporan? Apakah gudang data dapat diterima, atau apakah desainnya buruk karena menggabungkan logika bisnis dalam database dan data itu sendiri? Untuk menggabungkan data dari database menjadi data gudang data, Anda harus menerapkan logika bisnis dan aturan pada data, dan bahwa logika dan aturan itu tidak berasal dari model domain Anda, itu berasal dari proses pengumpulan data Anda. Apakah itu salah?
Saya bekerja pada aplikasi manajemen proyek dan keuangan yang besar di mana logika bisnisnya luas. Saat melaporkan data ini, saya akan sering memiliki BANYAK agregasi yang harus dilakukan untuk menarik informasi yang diperlukan untuk laporan / dasbor, dan agregasi memiliki banyak logika bisnis di dalamnya. Demi kinerja, saya telah melakukannya dengan tabel yang sangat teragregasi dan prosedur yang tersimpan.
Sebagai contoh, katakanlah sebuah laporan / dashboard diperlukan untuk menampilkan daftar proyek aktif (bayangkan 10.000 proyek). Setiap proyek akan membutuhkan serangkaian metrik yang ditunjukkan dengannya, misalnya:
- total anggaran
- upaya sampai saat ini
- tingkat pembakaran
- tanggal habis anggaran pada laju pembakaran saat ini
- dll.
Masing-masing melibatkan banyak logika bisnis. Dan saya tidak hanya berbicara tentang mengalikan angka atau logika sederhana. Saya sedang berbicara tentang untuk mendapatkan anggaran, Anda harus menerapkan lembar tarif dengan 500 tarif berbeda, satu untuk setiap waktu karyawan (pada beberapa proyek, yang lain memiliki pengganda), menerapkan biaya dan penambahan yang sesuai, dll. Logikanya luas. Butuh banyak agregasi dan penyetelan kueri untuk mendapatkan data ini dalam jumlah waktu yang wajar bagi klien.
Haruskah ini dijalankan melalui domain terlebih dahulu? Bagaimana dengan kinerja? Bahkan dengan query SQL langsung, saya hampir tidak mendapatkan data ini cukup cepat untuk ditampilkan klien dalam jumlah waktu yang wajar. Saya tidak bisa membayangkan mencoba untuk mendapatkan data ini ke klien cukup cepat jika saya rehydrating semua objek domain ini, dan mencampur dan mencocokkan dan menggabungkan data mereka di lapisan aplikasi, atau mencoba untuk mengumpulkan data dalam aplikasi.
Tampaknya dalam kasus-kasus ini SQL baik dalam mengolah data, dan mengapa tidak menggunakannya? Tetapi kemudian Anda memiliki logika bisnis di luar model domain Anda. Setiap perubahan pada logika bisnis harus diubah dalam model domain Anda dan skema agregasi pelaporan Anda.
Saya benar-benar bingung bagaimana merancang bagian pelaporan / dasbor aplikasi apa pun sehubungan dengan desain yang digerakkan domain dan praktik yang baik.
Saya menambahkan tag MVC karena MVC adalah desain rasa du jour dan saya menggunakannya dalam desain saya saat ini, tetapi tidak tahu bagaimana data pelaporan cocok dengan jenis aplikasi ini.
Saya mencari bantuan di bidang ini - buku, pola desain, kata kunci ke google, artikel, apa saja. Saya tidak dapat menemukan informasi tentang topik ini.
CONTOH EDIT DAN LAINNYA
Contoh sempurna lain yang saya jumpai hari ini. Pelanggan menginginkan laporan untuk Tim Penjualan Pelanggan. Mereka menginginkan apa yang tampak seperti metrik sederhana:
Untuk setiap Tenaga Penjualan, apa penjualan tahunan mereka sampai saat ini?
Tapi itu rumit. Setiap tenaga penjualan berpartisipasi dalam berbagai peluang penjualan. Sebagian mereka menang, sebagian lagi tidak. Dalam setiap peluang penjualan, ada beberapa orang penjualan yang masing-masing dialokasikan persentase kredit untuk penjualan sesuai peran dan partisipasi mereka. Jadi sekarang bayangkan melalui domain untuk ini ... jumlah rehidrasi objek yang harus Anda lakukan untuk menarik data ini dari database untuk setiap orang Sales:
Dapatkan semua
SalesPeople->
Untuk setiap mendapatkan merekaSalesOpportunities->
Untuk setiap mendapatkan persentase penjualan mereka dan menghitung jumlah Penjualan mereka
lalu Tambahkan semuaSalesOpportunityjumlah Penjualan mereka .
Dan itu SATU metrik. Atau Anda dapat menulis kueri SQL yang dapat melakukannya dengan cepat dan efisien dan menyesuaikannya dengan cepat.
EDIT 2 - Pola CQRS
Saya sudah membaca tentang Pola CQRS dan, meskipun menarik, bahkan Martin Fowler mengatakan itu tidak diuji. Jadi bagaimana masalah ini TELAH dipecahkan di masa lalu. Ini harus dihadapi oleh semua orang pada satu titik atau lainnya. Apa pendekatan yang mapan atau usang dengan catatan keberhasilan?
Edit 3 - Sistem / Alat Pelaporan
Hal lain yang perlu dipertimbangkan dalam konteks ini adalah alat pelaporan. Layanan Pelaporan / Crystal Reports, Layanan Analisis dan Cognoscenti, dll. Semua mengharapkan data dari SQL / database. Saya ragu data Anda akan datang melalui bisnis Anda nanti untuk ini. Namun mereka dan orang lain seperti mereka adalah bagian penting dari pelaporan di banyak sistem besar. Bagaimana data untuk ini ditangani dengan benar di mana bahkan ada logika bisnis dalam sumber data untuk sistem ini serta mungkin dalam laporan itu sendiri?
Jawaban:
Ini adalah jawaban yang sangat fasih, tetapi langsung menuju inti permasalahan:
Dalam hal DDD mungkin menganggap pelaporan sebagai Bounded Context ?, jadi daripada berpikir dalam hal model domain "THE", Anda harus mau berpikir bahwa boleh saja memiliki lebih dari satu model. Jadi ya tidak apa-apa jika domain pelaporan memiliki logika bisnis pelaporan di dalamnya, sama seperti tidak apa-apa bagi domain transaksional untuk memiliki logika bisnis transaksional di dalamnya.
Mengenai pertanyaan, misalkan prosedur tersimpan SQL vs model domain dalam kode aplikasi, pro dan kontra yang sama berlaku untuk sistem pelaporan seperti untuk sistem transaksional.
Karena saya melihat bahwa Anda menambahkan hadiah untuk pertanyaan, saya membaca pertanyaan itu lagi dan memperhatikan bahwa Anda meminta sumber daya spesifik tentang hal ini, jadi saya pikir saya akan mulai dengan menyarankan agar Anda melihat pertanyaan Stack Overflow lainnya mengenai masalah ini, dan saya menemukan ini https://stackoverflow.com/questions/11554231/how-does-domain-driven-design-handle-reporting
Inti umum dari hal itu adalah menggunakan CQRS sebagai pola untuk sistem Anda, yang konsisten dengan DDD, dan bergantung pada tanggung jawab sisi permintaan sebagai cara untuk menyelesaikan pelaporan, tetapi saya tidak yakin itu adalah jawaban yang bermanfaat dalam kasus Anda.
Saya juga menemukan ini http://www.martinfowler.com/bliki/ReportingDatabase.html , yang saya temukan ditautkan dari sini: http://groups.yahoo.com/neo/groups/domaindrivendesign/conversations/topics/2261
Berikut ini adalah artikel yang menarik dari ACM tentang masalah ini: http://dl.acm.org/citation.cfm?id=2064685 tapi itu di belakang paywall jadi saya tidak bisa membacanya (bukan anggota ACM :().
Ada juga jawaban ini di sini untuk pertanyaan serupa: https://stackoverflow.com/questions/3380431/cqrs-ddd-synching-reporting-database
dan yang ini: http://snape.me/2013/05/03/applying-domain-driven-design-to-data-warehouses/
Semoga ini membantu!
sumber
Pemahaman saya dari pertanyaan Anda adalah ini: Aplikasi untuk tugas sehari-hari miliki
Lihat >> Pengendali >> Model (BL) >> Database (Data)
Aplikasi untuk tujuan pelaporan
Lihat >> Pengendali >> Model >> Basis Data (Data + BL)
Jadi perubahan BL untuk ' aplikasi tugas ' akan menyebabkan perubahan dalam ' pelaporan ' BL juga. Itu masalah Anda yang sebenarnya, kan? Yah tidak apa-apa untuk melakukan perubahan dua kali, rasa sakit yang harus Anda ambil pula. Alasannya adalah kedua BL dipisahkan oleh kekhawatiran masing-masing. Satu untuk mengambil data dan satu untuk mengumpulkan data. Juga, BL asli Anda dan agregasi BL akan ditulis dalam berbagai teknologi atau bahasa ( C # / java dan SQL proc ). Tidak ada jalan keluar untuk itu.
Mari kita ambil contoh lain yang tidak terkait dengan pelaporan khusus. Misalkan suatu perusahaan XXX melacak email dari semua pengguna untuk interpretasi dan menjual info itu kepada perusahaan pemasaran. Sekarang akan memiliki satu BL untuk interpretasi dan satu BL untuk mengumpulkan data untuk perusahaan pemasaran. Kekhawatiran berbeda untuk kedua BL. Besok jika BL mereka berubah sehingga surat-surat yang datang dari Kuba harus diabaikan, maka logika bisnis akan diubah di kedua sisi.
sumber
Pelaporan adalah konteks terbatas, atau subdomain, untuk berbicara secara longgar. Ini memecahkan kebutuhan bisnis untuk mengumpulkan / mengumpulkan data dan memprosesnya untuk mendapatkan intelijen bisnis.
Bagaimana Anda menerapkan subdomain ini mungkin akan menjadi keseimbangan antara (sebagian) cara arsitektur yang benar Anda bisa melakukan ini, dan apa infrastruktur Anda akan memungkinkan. Saya suka memulai dari sisi yang pertama, dan bergerak ke arah yang terakhir hanya seperlunya.
Anda mungkin dapat membaginya menjadi dua masalah utama yang sedang Anda pecahkan:
Menggabungkan, atau menyimpan data. Ini harus memproses beberapa sumber data, dan menggabungkan informasi sedemikian rupa sehingga disimpan di sumber data lain.
Meminta sumber data teragregasi untuk memberikan intelijen bisnis.
Tak satu pun dari masalah itu merujuk pada database atau mesin penyimpanan tertentu. Lapisan domain Anda seharusnya hanya berurusan dengan antarmuka, diimplementasikan di lapisan infrastruktur Anda oleh berbagai adapter penyimpanan.
Anda mungkin memiliki berbagai pekerja atau beberapa pekerjaan yang dijadwalkan, yang dibagi menjadi beberapa bagian yang bergerak:
Semoga Anda bisa melihat beberapa CQRS bersinar di sana.
Di sisi pelaporan, seharusnya hanya perlu melakukan kueri, tetapi tidak pernah secara langsung ke dalam basis data. Pergi melalui antarmuka Anda dan melalui lapisan domain Anda di sini. Ini bukan domain masalah yang sama dengan tugas utama Anda, tetapi masih harus ada logika di sini yang ingin Anda patuhi.
Segera setelah Anda terjun langsung ke basis data, Anda lebih bergantung padanya, dan pada akhirnya dapat mengganggu kebutuhan data aplikasi asli Anda.
Juga, setidaknya bagi saya, saya pasti lebih suka menulis tes dan mengembangkan kode daripada pertanyaan atau prosedur tersimpan. Saya juga suka tidak mengunci diri ke alat khusus sampai benar-benar diperlukan.
sumber
Biasanya memisahkan data operasional / transaksional dari pelaporan. Yang terakhir mungkin memiliki persyaratan untuk menyimpan data untuk alasan hukum (mis. Tujuh tahun data keuangan untuk audit keuangan), dan Anda tidak menginginkan semua itu di penyimpanan data transaksional Anda.
Jadi, Anda akan mempartisi data transaksional Anda berdasarkan ukuran waktu (mingguan, bulanan, triwulanan, tahunan) dan memindahkan partisi lama ke dalam penyimpanan data pelaporan / riwayat Anda melalui ETL. Ini mungkin atau mungkin bukan gudang data dengan skema dan dimensi bintang. Anda akan menggunakan alat pelaporan pergudangan data untuk melakukan permintaan ad hoc dan roll up dan pekerjaan batch untuk menghasilkan laporan berkala.
Saya tidak akan merekomendasikan melaporkan terhadap penyimpanan data transaksional Anda.
Jika Anda lebih suka menekan, berikut ini lebih banyak pemikiran:
Perangkat lunak manajemen proyek yang Anda gunakan di rumah? Saya akan membeli sebelum membangun. Sesuatu seperti Rally dan Microsoft Project.
sumber
Pertama beberapa terminologi, apa yang Anda sebut sisi tugas dikenal sebagai Transaksional dan sisi Pelaporan adalah Analytics.
Anda telah menyebutkan CQRS yang merupakan pendekatan hebat tetapi ada sedikit aplikasi praktis dari pendekatan tersebut.
Apa yang telah sangat diuji adalah melengkapi pemrosesan Transaksional Anda dengan mesin pemrosesan Analitik. Ini kadang-kadang disebut sebagai Data Warehousing atau Data Cubes. Gotcha terbesar berkaitan dengan analytics adalah bahwa mencoba menjalankan query terhadap data transaksional Anda secara real-time paling tidak efisien karena sangat mungkin hanya mengoptimalkan database untuk membaca atau menulis. Untuk transaksi, Anda ingin kecepatan tulis yang tinggi untuk menghindari keterlambatan dalam memproses / melakukan sesuatu. Untuk pelaporan, Anda ingin kecepatan baca tinggi sehingga keputusan dapat dibuat.
Bagaimana cara menjelaskan masalah ini? Pendekatan paling sederhana untuk dipahami adalah menggunakan skema rata untuk pelaporan Anda dan ETL (ekstrak transform load) untuk mengirim ulang data dari skema transaksional yang dinormalisasi ke skema analitis denormalized. ETL dijalankan melalui agen secara teratur dan memuat tabel analitik sehingga siap untuk dibaca cepat dari mesin pelaporan Anda.
Buku bagus untuk mengetahui kecepatan pergudangan data adalah Data Warehouse Toolkit oleh Ralph Kimball. Untuk pendekatan lebih dekat. Unduh uji coba SQL Server dan ambil toolkit Gudang Data Microsoft yang mengambil pembahasan umum buku pertama tetapi menunjukkan bagaimana menerapkan konsep menggunakan SQL Server.
Ada beberapa buku yang ditautkan dari halaman-halaman yang membahas lebih detail tentang ETL, Desain Skema Bintang, BI, Dasbor, dan topik lainnya untuk membantu Anda mengikuti.
Cara tercepat untuk pergi dari tempat Anda berada ke tempat yang Anda inginkan, adalah dengan menyewa Ahli BI dan membayangi dia saat dia mengimplementasikan apa yang Anda butuhkan.
sumber
Mengambil sejumlah besar informasi melalui jaringan area luas, termasuk Internet, bermasalah karena masalah yang timbul dari latensi respons, kurangnya akses memori langsung ke sumber daya penyajian data, dan toleransi kesalahan.
Pertanyaan ini menjelaskan pola desain untuk menyelesaikan masalah penanganan hasil dari kueri yang mengembalikan sejumlah besar data. Biasanya pertanyaan ini akan dibuat oleh proses klien di jaringan area luas (atau Internet), dengan satu atau lebih tingkat menengah, ke basis data relasional yang berada di server jauh.
Solusi ini melibatkan penerapan kombinasi strategi pengambilan data, termasuk penggunaan iterator untuk melintasi set data dan memberikan tingkat abstraksi yang tepat kepada klien, buffer ganda subset data, pengambilan data multi-threaded, pengambilan data multi-threaded, dan slicing query.
sumber
Saya tidak berpikir Anda berbicara tentang logika bisnis, ini lebih merupakan logika pelaporan. Apa yang dilakukan pengguna dengan informasi di layar ini, apakah itu hanya untuk pembaruan status? Model domain Anda digunakan untuk memodelkan operasi transaksional, pelaporan adalah masalah yang berbeda. Menarik data dari SQL Server atau memasukkannya ke dalam data warehouse baik untuk melaporkan skenario.
Model domain Anda harus memberlakukan invarian domain Anda seperti anggota proyek tidak dapat memesan ke proyek yang sama secara bersamaan, atau hanya dapat memesan x jumlah jam seminggu. Atau Anda tidak dapat memesan untuk proyek ini karena sudah selesai dll. Keadaan model domain Anda (data) dapat disalin untuk pelaporan secara terpisah.
Untuk meningkatkan kinerja kueri, Anda dapat menggunakan tampilan terwujud. Ketika suatu operasi dilakukan terhadap model Anda (mis. Buku 4 jam dari waktu orang ini untuk memproyeksikan x) dan berhasil, ia dapat melempar suatu peristiwa yang kemudian dapat Anda simpan dalam database pelaporan dan membuat perhitungan yang diperlukan untuk laporan Anda. Maka akan sangat cepat untuk menanyakannya.
Pisahkan konteks transaksi dan pelaporan Anda, sebuah basis data relasional dibuat untuk melaporkan model domain yang tidak.
SUNTING
Posting blog yang bermanfaat tentang subjek http://se-thinking.blogspot.se/2012/08/how-to-handle-reporting-with-domain.html
sumber
Sudah 4 tahun kemudian dan saya baru saja menemukan pertanyaan ini lagi, dan saya punya apa, bagi saya, jawabannya.
Bergantung pada aplikasi Anda dan kebutuhan spesifiknya, basis data domain / transaksi dan pelaporan Anda dapat berupa "sistem" atau "mesin" yang terpisah, atau dapat dilayani oleh satu sistem. Namun, mereka harus terpisah secara logis - yang berarti mereka menggunakan cara berbeda untuk mengambil dan menyediakan data ke UI.
Saya lebih suka mereka terpisah secara fisik (selain terpisah secara logis), tetapi banyak kali Anda memulainya bersama-sama (secara fisik) dan kemudian, saat aplikasi matang, Anda memisahkannya.
Either way, sekali lagi, mereka harus berbeda secara logis. Tidak masalah menggandakan logika bisnis dalam sistem pelaporan. Yang penting adalah bahwa sistem pelaporan mendapatkan jawaban yang sama dengan sistem domain - tetapi kemungkinan itu akan sampai di sana melalui cara yang berbeda. Misalnya, sistem domain Anda akan memiliki banyak aturan bisnis yang sangat ketat diimplementasikan dalam kode prosedural (kemungkinan). Sistem pelaporan dapat mengimplementasikan aturan-aturan yang sama ketika membaca data tetapi akan melakukannya melalui kode berbasis SET (mis. SQL).
Inilah evolusi arsitektur aplikasi Anda yang terlihat realistis saat berevolusi:
Level 1 - Domain terpisah dan sistem pelaporan, tetapi masih dalam basis kode dan database yang sama
Level 2 - Domain yang dipisahkan secara logis dan sistem pelaporan, tetapi pisahkan basis data sekarang, dengan sinkronisasi.
Level 3 - Domain dan sistem pelaporan yang dipisahkan secara Fisik dan Fisik, dan pisahkan basis data dengan sinkronisasi.
Gagasan utamanya adalah bahwa pelaporan dan domain memiliki kebutuhan yang sangat berbeda. Profil data yang berbeda (membaca vs menulis dan memperbarui frekuensi), persyaratan kinerja yang berbeda, dll. Jadi mereka perlu diimplementasikan secara berbeda, dan itu memerlukan beberapa duplikasi logika bisnis.
Terserah bisnis Anda untuk menemukan cara untuk menjaga agar logika bisnis dari domain dan sistem pelaporan tetap mutakhir.
sumber
Keadaan setiap proyek harus disimpan sebagai informasi statis, per-perhitungan, dan diformat dengan baik dalam database dan setiap simulasi harus ditangani pada klien sebagai WebApp.
jenis proyeksi ini tidak boleh dijalankan atas permintaan. Mengelola informasi ini berdasarkan permintaan, seperti melakukan perhitungan pada sumber daya, tingkat, tugas, tonggak, dll, akan menghasilkan penggunaan yang luas dari lapisan perhitungan tanpa menggunakan kembali hasil ini untuk panggilan selanjutnya.
Membayangkan lingkungan terdistribusi ( cloud pribadi atau publik ), Anda akan mendapatkan biaya yang sangat besar di lapisan komputasi, rendahnya penggunaan basis data, dan total kekurangan cache.
Desain perangkat lunak Anda harus mencakup kemampuan untuk melakukan normalisasi perhitungan yang diperlukan untuk mendapatkan hasil yang diperlukan selama "input data", bukan saat membaca. Pendekatan ini sangat mengurangi penggunaan sumber daya komputasi, dan di atas semua itu menciptakan tabel yang dapat dianggap sebagai "hanya baca" oleh pelanggan. Ini adalah langkah pertama untuk membuat mekanisme caching yang solid dan sederhana.
Jadi cari dulu, sebelum menyelesaikan arsitektur perangkat lunak, bisa jadi Distributed Cache System .
(permintaan: agregasi)! = 1: 1
Karena itu pertimbangan saya (untuk contoh pertama dan kedua), cobalah untuk memahami kapan waktu yang tepat untuk menormalkan data, memiliki sebagai tujuan untuk mengurangi agregasi per permintaan klien. Yang tidak bisa 1: 1 (permintaan: agregasi) jika satu tujuan memperoleh sistem yang berkelanjutan.
Bagikan perhitungan pada klien
Pertanyaan lain, sebelum menyelesaikan desain perangkat lunak, bisa jadi, berapa normalisasi, kita ingin mendelegasikan browser klien?
Itu bernama MV *, memang benar bahwa itu modis hari ini, di samping ini, salah satu tujuannya adalah untuk membuat WebApp (aplikasi halaman tunggal), yang dapat dianggap sebagai hadirnya banyak aplikasi yang kompleks (dan untungnya untuk tagihan yang kami membayar ke penyedia cloud, ini dieksekusi di klien).
Oleh karena itu kesimpulan saya adalah:
Memahami berapa banyak operasi yang benar-benar diperlukan untuk melaksanakan penyajian data;
Menganalisis berapa banyak dari ini dapat dilakukan di latar belakang (dan kemudian didistribusikan melalui sistem cache, setelah normalisasi mereka);
Memahami berapa banyak operasi yang dapat dieksekusi di klien, mendapatkan konfigurasi proyek, menjalankannya pada Views di WebApp dan dengan demikian mengurangi perhitungan yang dilakukan di back-end;
sumber
Gunakan cache untuk kueri, gunakan domain untuk caching.
Ada fitur yang disebut "pengguna teratas" di stackoverflow. Anda dapat menemukan baris di buttom halaman pengguna teratas, mengatakan "Hanya pertanyaan dan jawaban non-komunitas wiki yang termasuk dalam total ini ( diperbarui setiap hari )". Ini menunjukkan data di-cache.
Tapi kenapa?
Untuk masalah kinerja mungkin. Mungkin mereka memiliki keprihatinan yang sama dengan kebocoran domain logika ("Hanya pertanyaan dan jawaban non-komunitas-wiki yang dimasukkan dalam total ini" dalam kasus ini).
Bagaimana?
Saya tidak benar-benar tahu bagaimana mereka melakukan ini, jadi ini hanya dugaan :)
Pertama, kita perlu menemukan target pertanyaan / jawaban. Tugas penjadwalan dapat bekerja, cukup ambil semua target potensial.
Kedua, mari kita lihat hanya satu pertanyaan / jawaban. Apakah ini bukan komunitas-wiki? Apakah dalam 30 hari? Cukup mudah untuk menjawab dengan model domain. Hitung suara dan cache jika puas.
Sekarang kita memiliki cache, mereka adalah output dari turunan domain. Permintaannya cepat dan mudah karena hanya ada kriteria sederhana untuk diterapkan.
Bagaimana jika hasilnya harus lebih "real time"?
Acara dapat membantu. Alih-alih memicu caching dengan tugas penjadwalan, kami dapat membagi proses menjadi banyak sub-proses. Misalnya, ketika seseorang memberikan suara pada jawaban hippoom, kami menerbitkan acara yang memicu pembaruan cache pengguna teratas hippoom. Dalam hal ini, kita mungkin sering melihat tugas kecil cepat.
Apakah CQRS perlu?
Baik dengan pendekatan tugas penjadwalan maupun dengan pendekatan peristiwa. Tetapi cqrs memang memiliki keunggulan. Cache biasanya sangat berorientasi pada tampilan, jika beberapa item tidak diperlukan pada awalnya, kami mungkin tidak menghitung dan menyimpannya sama sekali. CQRS dengan sumber acara membantu mengkonsep ulang cache untuk data historis dengan memutar ulang acara.
Beberapa pertanyaan terkait:
1. https://stackoverflow.com/questions/21152958/how-to-handle-summary-report-in-cqrs 2. https://stackoverflow.com/questions/19414951/how-to-use -kaya-domain-dengan-operasi-besar-besaran / 19416703 # 19416703
Semoga bermanfaat :)
sumber
Penafian:
Saya cukup berpengalaman dalam aplikasi dengan model domain.
Saya memahami semua konsep, dan saya sudah lama berpikir tentang bagaimana menerapkan konsep-konsep ini ke aplikasi yang saya kerjakan (yang kaya domain, tapi kurang OO, model domain aktual, dll . ) .
Pertanyaan ini adalah salah satu masalah utama yang saya hadapi juga. Saya punya ide bagaimana menyelesaikan ini, tetapi seperti yang saya katakan ... itu hanya ide yang saya buat.
Saya belum mengimplementasikannya dalam proyek yang sebenarnya, tetapi saya tidak melihat alasan mengapa itu tidak berhasil.
Sekarang saya sudah menjelaskannya, inilah yang saya buat - saya akan menggunakan contoh pertama Anda (metrik proyek) untuk menjelaskan:
Ketika seseorang mengedit proyek, Anda memuat dan menyimpannya melalui model domain Anda.
Pada saat ini, Anda memiliki semua informasi yang dimuat untuk menghitung semua metrik Anda (total anggaran, upaya hingga saat ini, dll.) Untuk proyek ini.
Anda dapat menghitung ini dalam model domain, dan menyimpannya ke database dengan sisa model domain.
Jadi
Projectkelas dalam model domain Anda akan memiliki beberapa properti sepertiTotalBudget,EffortToDatedll., Dan juga akan ada kolom dengan nama-nama dalam tabel database di mana model domain Anda disimpan (dalam tabel yang sama, atau dalam tabel yang terpisah ... tidak itu penting) .Tentu saja, Anda perlu melakukan satu kali lari untuk menghitung nilai untuk semua proyek yang ada saat Anda mulai dengan ini. Tetapi setelah itu, data diperbarui secara otomatis dengan nilai yang dihitung saat ini setiap kali proyek diedit melalui model domain.
Jadi, setiap kali Anda memerlukan laporan apa pun, semua data yang diperlukan sudah ada (pra-dihitung) dan Anda bisa melakukan sesuatu seperti ini:
Tidak masalah apakah Anda mendapatkan data secara langsung dari tabel tempat model domain disimpan, atau jika Anda entah bagaimana mengekstrak data ke database kedua, ke gudang data atau apa pun:
Dalam kedua kasus tersebut, logika bisnis untuk penghitungan berada tepat di satu tempat: model domain.
Anda tidak memerlukannya di tempat lain, jadi Anda tidak perlu menduplikasinya.
sumber