Auditing Context

[Sammo]

In our system we have several Bounded Contexts. Pricing, Fulfilment, Enrichment and DocumentGeneration are an example of a few of them. 

Recently we have discussed adding a new Auditing context, that being a generic piece that allows us access to data artefacts either generated by the other contexts, or recorded by them when 'flowing through'. The artefacts in question here are things like customer risk data, risk enrichments, etc. 

My question is this, is it OK to have a separate context for this, or should you request that information directly from each context as necessary? Does the new Auditing context effectively force 'leakage' out of artefacts that should stay within those contexts? 

[Ben Kloosterman]

Auditing like this is more read side and the ES write data source is your audit log  . What sort of business logic / commands are we looking at ? 

"risk data, risk enrichments " These look like BCs to me eg what determines what is risky ?  My first thought  pub /sub on the event stream and create a ( many ?)  custom risk data Audit store as the business requires and then query that . 

Ben

[Chris Sampson]

I should have mentioned that we don't use ES (yet - and then it would depend on the context). 

An example of BC command/event flow would be Pricing(context)->RiskRated->Auditing(context)->StoreAuditData where (currently) the risk data artefact is carried on the RiskRated event and passed on by process manager into the AuditingContext by the StoreAuditData command.

its the idea of passing the data out of the context into another that I am not sure about - If you believe that a context should be in control of its own data and not leak it out to other contexts.

Risk is the information used to calculate a premium value for a prospective insurance policy

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ben Kloosterman]

With ES its quite common to pass events out and have other context / apps use them ,  for non ES less so though report servers often fall into this category,

Even when not using Event sourcing fro auditing I have created events which can then be subscribed  by other consumers.The other way you end up running large and expensive queries so its better to move them out .

The risk parts are definitely a BC but  I would not use the term Audit ( except for a business Audit ) 

 eg  Pricing(context)->RiskRated->HistoricalRisk(context)->StoreRiskData.

Ben

[Chris Sampson]

Thanks for that, maybe 'Audit' is a bit of a broad term, I'll speak to the team as regards naming.

On Risk being its own BC, Risk is information that 'flows' through Enrichment and Pricing contexts. It would be difficult making a Risk BC without changing the boundaries of those contexts, It would effectively be a union of those contexts - Pretty large.

--

[Sammo]

Sorry, please ignore the last part of my last comment, I see what you mean now about Risk being its own context - HistoricalRisk for the archived artefacts.

To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+unsubscribe@googlegroups.com.

[Ben Kloosterman]

The name change means you will better think about this in business terms not audit infrastructure .  It may use infrastructure ( eg send messages on Create /Update/Delete then pub sub)  but at least it should give clearer business logic/requirements / terms and the infrastructure is not the driver.

To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.

To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.

[Chris Sampson]

One question I do have about this is that these artefacts can be quite large lugs of xml, and currently we have them on the event. If we were to move to ES would this be an issue in terms of event serialisation speed/size etc? Thus should we store the artefact separately to the event?  If so where? 

[Ben Kloosterman]

It depends on how big id setup a microbench.

With a bit of work you should be able to load and serialized 20 Meg in less than 1/10 of a second.  If its too big snapshot the data or put them in a separate data store ,  xml blobs store much better in event stores/ files/ table stores than a DB .   

http://maxondev.com/serialization-performance-comparison-c-net-formats-frameworks-xmldatacontractserializer-xmlserializer-binaryformatter-json-newtonsoft-servicestack-text/  here they have 364K serialize in about 11ms. 

Its more a  question of data storage ..  In my case fetching large blobs by key was much faster than say querying 10-12 SQL tables. Remember latency in non cached IO  is significant. 

If you treat it right XML blobs / messages go very far . If you do stupid things eg completely default generation of complex objects , serializing data sets you will quickly be in trouble.  

Also with XML removing all namespaces , using smart default values and small names can reduce the size significantly ( a factor of 2-3) . It also compresses very well 10:1 can be common for large XML blobs  ( a single request will be slightly slower ( especially if data cached) but your not hogging all the disk IO so you get more requests) .

The big thing to be careful of with XML blobs is re writing large ones on small changes but this is not really an issue for this. 

Ben