I just have to add that - with our arrogance as software developers - „we“ have educated domain experts to think in „things“ … and change their role to be „product owners“. 😉
How does reporting work? All report engines I know about expect a database. Would you have some scheduled job or event listener that lifts event data into a read-only database schema? So this reporting schema would be a secondary data store for the purpose of supporting reports, and not the real primary data store?
Reporting works on a projection, ie. on a model specific for that purpose. Such models can be persistent. Use any technology you like.
Reporting is a great example for a request requiring a particular view on data. If so far you based a report on a view or had the report do a projection itself, it can now become simpler. It can be run on a tailored projection. Less logic needed in the report, more logic kept where it can easily be modified and versioned.
Beautifully written, Ralf! 😀
I just have to add that - with our arrogance as software developers - „we“ have educated domain experts to think in „things“ … and change their role to be „product owners“. 😉
True!😁 And sad.
How does reporting work? All report engines I know about expect a database. Would you have some scheduled job or event listener that lifts event data into a read-only database schema? So this reporting schema would be a secondary data store for the purpose of supporting reports, and not the real primary data store?
Reporting works on a projection, ie. on a model specific for that purpose. Such models can be persistent. Use any technology you like.
Reporting is a great example for a request requiring a particular view on data. If so far you based a report on a view or had the report do a projection itself, it can now become simpler. It can be run on a tailored projection. Less logic needed in the report, more logic kept where it can easily be modified and versioned.