Latest Replies
Thursday
Nov242011

Importance of Good Domain Models

You might find that I will be writing less about the technical side of event centric systems (with all the CQRS, ES and cloud aspects) along with the problems of scaling and improving their performance. This is because all that is a solved problem in the industry (the only question is about costs and risks of any given solutions).

There is a more important problem at hand - coming up with proper domain models that actually represent useful abstraction of the real world and allow event centric systems to be delivered. Or, in other words, coming up with a description of problem domain, that is structured in such a way, that you could easily build a system with that.

DDD might sound like less exciting topic for discussion as compared to elastic scalability, clouds or why LMAX can get millions of messages. However the former is just the implementation detail, if you have adequate model. Unless you are doing something really specific with the technology, all problems you would face - have already been solved by many people. That's pure engineering (albeit not the one with a lot of documentation on top of that). You can have more-or-less predictable results, given the initial design in almost any field (aside from areas where technology is so important that it starts melding into the domain field - there really cool things start showing up).

Design of domain models is something more of an art or a craft. Given the domain field, you are not guaranteed to arrive at satisfactory model. You are not guaranteed anything at all. Hence it is more of a problem that needs solution.

However, if you arrive at something satisfactory, you would get domain model that could easily outlast any technological changes, while even making them less relevant (less expensive and less risky)

« Store and forward for Event Streams | Main | Lifehack: Query Multiple Aggregates from Event Stream »

Reader Comments (4)

I agree whole-heartedly, even though some technology choices (like for example CQRS) can be useful in that they really encourage designing a proper domain model to begin with, the domain model is in the end what will remain in a couple of years when the technology around it changes.

November 24, 2011 | Unregistered Commenterdownwind

Yes, absolutely. Actually certain technologies of "CQRS Stack" even simplify domain modeling process a bit. For example, using code with AR+ES and maybe specs to capture core entities and relations between them, and maybe even reveal new aspects of this domain knowledge.

November 25, 2011 | Registered CommenterRinat Abdullin

I'm glad that you are arriving to this conclusion. The more you learn about it the more you will understand that it is not really a black art :)

I guess that CQRS can be used as a catalyst for full DDD immersion :)

As we are this. Have you ever thought using first order logic on top of your fact streams to implement some kind of self diagnostic system against a running system?

If you have some things or ideas about this please send me a message.

If not, then some food for thought maybe (SEEEDING ..)

November 28, 2011 | Unregistered CommenterNuno Lopes

Nuno, I'm not really familiar with "first order logic" (aside from reading wiki article on that right now). However, where I come from, people were using events for unsupervised learning and modeling (including forecasting). Also an interesting deviation was the use of specialized neural networks for real-time detection and recognition of patterns (this was in systems with critical messaging). Obviously, there are a lot of nuances (and alternatives), and applicability depends on the specific domain and resources available.

November 29, 2011 | Registered CommenterRinat Abdullin

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>