This is a topic I know nothing about, and thus, may be supremely disparate notes. Have fun translating. : ) . . .and coolness that the session is well past capacity. Separates things form the UI and everything that needs populated is done through commands. The domain and reports have separate storage. Events populate these stores of data, such as "sold event". What it looks like, is that the domain controls the requests by event, which would be a product order or something similar. Event sourcing is a key element of the logic. DDD (Domain Driven Design) is part of the core basis for this methodology/structure. The architecture/methodology/structure is perfect for blade style plugin hardware as needed. Good blog entry DDDD: Why I love CQRS and another Command and Query Responsibility Segregation (CQRS), more, CQRS à la Greg Young, a bit by Udi Dahan and there are more. Google, Bing, etc are there for a reason. It appears the core underpinning architectural element of this is the break out of unique identifiable actions, or I suppose better described as events. Those events then act upon specific pipelines such as read requests, write requests, etc. I will be doing more research on this topic and will have something written up shortly. At this time it seems like nothing new, just a large architectural break out of identifiable needs of the entire enterprise system. The reporting is in one segment of the architecture, the domain is in another, hydration broken out to interfaces, and events are executed to incur events on the Reports, or what appears by the description to be events on the domain. Anyway, more to come on this later.
