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 semuaSalesOpportunity
jumlah 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?