Using CQRS and DDD principles in simpler projects

[sudarshan]

Hi All,

From what i understand of CQRS and DDD there seems to be a consensus
among st the leading practitioners that both these "ideas" should be
applied only in "niche" domains where the business derives competitive
advantage.

I would imagine that a lot of us work in more regular/mature domains
can principles from CQRS/DDD help us build better software for these
domains as well ?

I think the below principles in particular can be applied to most
domains, and here i do not mean distributed applications

1) Just separating out my reads from writes having 2 separate models
(Need not be implement persistence via ES)

2) Having a commandbus,handler to separate out the server side logic
from the client/controller

3) Having events published via some in memory queue , maybe in the
same transaction, need not be Eventually consistent.

4) Thinking in terms of AR's,VO,Repositories,Factories ...



I could add a few more, however i am eager to know the communities
views on this ....

What do most of us do for domains which lie in between clear CRUD and
highly distributed/complex systems ?

Thanks

[Werner Clausen]

My 2c:

 

> What do most of us do for domains which lie in between clear CRUD

> and highly distributed/complex systems ?

 

Everything. Seriously, that is probably what you should do. It all depends on what your needs are. And different scenarios calls for different solutions. I think "yreynhout" says it well in another answer to you. If DDD/CQRS fits in your scenario then use it. But at least think about if it fits. This is just common sense - it does not evolve around DDD/CQRS in particular. However, what I hear from the leading people here is just, that applying DDD/CQRS(ES) will increase complexity to your solution, and in many cases the payoff just doesn't match up to your DDD/CQRS investment.

 

You know, "do not cross the river to get water" it an excellent advice. But if you realize that the water in the river is contaminated - then you should cross the river. So there might be noumerous reasons for you to use DDD/CQRS, and if you think those reasons justify the complexity it brings, then by all means use it! But as Udi Dahan says, just don't see it as a silver bullet. Use the tools that fit your needs.

 

Werner

 

 

 

[Sharas]

CRUD is not an alternative to DDD. CRUD is part of DDD. When you practise DDD you have to recognize where to apply CRUD.

[satish venkatakrishnan]

According to me DDD is about solving a problem and you can solve the problem efficiently with CRUD in some cases and CQRS in some cases,

But we need to identify the bound ires ,i think its the community duty to fit this circle correctly

[ashic]

One of the things I find odd is that CQRS, Event Sourcing, DDD is
often seen as "one big thing" for massively complicated projects. IMO,
it's more a collection of small parts that when combined together can
make massively complicated projects easier. This does not mean that
the smaller parts can't be used for smaller things. The nice thing
about it is that it enables you to improve / upgrade your
infrastructure if and when needed without having to modify application
code. This is a big benefit that is applicable to any project -
adhering to the open closed principle is not the worst you could do.
I've used various components of CQRS / ES / DDD in various scenarios
and my rule of thumb recommendation is:

1. Complicated domain that delivers business advantage and benefit -
go for it.
2. Simple domain and you're looking to take on complicated one soon -
go for it as part of training / learning. You can't really jump head
first into a large project without understanding of messaging and a
smaller project may be good in this case.
3. Simple domain where you can see "ifs" and "whens" being added quite
soon and scalability is likely a factor - go for it. By the time
you've created your relational model using a traditional approach,
you'll already be delivering value.
4. Simple domain and you already have components from a previous
larger project - (Event Store, message bus / aggregator, testing
infrastructure etc.) - go for it.
5. No idea about CQRS / ES and need to deliver within weeks - stick to
what you got.
6. Efficient in CQRS / ES and part of project is genuinely CRUD, data
will never be interpreted in different ways, complexity will not rise
- simply use a 2 tier CRUD approach. Keep it very simple so if
complexity does increase, you can switch to messaging and wouldn't
have wasted too much effort.
7. You identify something that can benefit from either CQRS or ES, use
what's most appropriate in that scenario. For example, I recently did
some excel parsing where instead of attempting to create a complicated
"object model", I simply parsed in events and stored them in xml. I
event sourced a query interface from those events to give me exactly
what I need. Even if excel format changes, everything else would be
fine. And if I need more ways of getting that data, I can add that
feature to the event sourced query provider. There's no CQRS there,
but using ES has definitely been beneficial in this case.

I'm sure there can be more stuff but those are what I can think of
from the top of my head.

On Jan 23, 11:51 am, satish venkatakrishnan <satish...@gmail.com>
wrote:

[sudarshan]

Yup thanks, I think i needed some re enforcement that CQRS,ES and DDD
are all implementable independently :)

and that its cool to pick and choose the implementation techniques for
each of these concepts based on the problem domain ....

[Tom Janssens]

For me the key point in CQRS is that it requires you to model every
single possible domain transition/interaction explicitly.

In essence:
- In CRUD you have to model explicitly what the user can not do
- In CQRS you have to model explicitly what the user can do

I tried removing most of the protocol required in numerous CQRS
examples, but I found out in most real-life situations CQRS adds a lot
of overhead due to it's explicit nature; which is quite natural once
you think about it...

In most complex environments it is easier to build rules about what is
not allowed, then to build rules about what is allowed.

For the record, I tried using CQRS in lots of situations, but found
out every single time I was better of without it...

[satish venkatakrishnan]

May be in other words.. where really CQRS fits.. if Complex system ,what is really mean by complex system.. how come all complex system needs CQRS..

IMHO CQRS Solves a specific problem in a good finding the good way really and applying it gonna give benfit.. right now most of my system used as a one architecture for all the problem and people started thinking CQRS is a worst design pattern.. so please advice us where really CQRS fits and where it is not ... 

[sudarshan]

When you say "CQRS" you implicitly mean CQRS and ES right ?

On Jan 25, 6:35 pm, satish venkatakrishnan <satish...@gmail.com>
wrote:

[ashic]

I would disagree with that quite a bit. In most complex environments,
what "can be done" today may not be done tomorrow. What cannot be done
today can be a mere warning tomorrow. What can be atomically
consistent today may not be possible tomorrow (due to much more data,
users, collaboration etc.). In CRUD you have to agree up front about a
data model that is supposed to suit all future requirements and
changes to that mean complex migration. With event sources, changes
driven by the business regarding rules and what not do not affect any
of that. Infrastructure and business processing is separated and
there's more freedom to evolve either or both orthogonally.

@satish & sudarshan:
As I've mentioned above, CQRS isn't one big thing. If we were to take
it as "one thing", it is merely having different channels to query
data and change the system. That's hardly interesting. The main
benefit comes when used with other patterns and principles - Event
Sourcing, Messaging, DDD etc. It's an enabling pattern. What this also
means is that you can pick and combine these things to match your
needs. So asking where CQRS is applicable is pointless - as it's like
asking where can a screw be used.

If by CQRS you mean the combination of CQRS, ES, DDD etc. then my
previous reply points that out. Typically if you anticipate (or are
faced with) business logic with "when", "ifs" etc., it may be a good
idea. If the same information is to be used in a number of different
ways, it's definitely worth investigating.

[Tom Janssens]

Op donderdag 26 januari 2012 10:20:16 UTC+1 schreef ashic het volgende:

I would disagree with that quite a bit. In most complex environments,
what "can be done" today may not be done tomorrow. What cannot be done
today can be a mere warning tomorrow. What can be atomically
consistent today may not be possible tomorrow (due to much more data,
users, collaboration etc.). In CRUD you have to agree up front about a
data model that is supposed to suit all future requirements and
changes to that mean complex migration. With event sources, changes
driven by the business regarding rules and what not do not affect any
of that. Infrastructure and business processing is separated and
there's more freedom to evolve either or both orthogonally. 

Let's say you add a property; in CRUD you add it once, and it is available everywhere, while in CQRS you have to add it to the relevant commands and handlers everywhere explicitly ...

 

[Peter Ritchie]

It's unclear to me *why* people are making a differentiation between CRUD and CQRS (or DDD for that matter).

The applicability of CQRS in my mind is the applicability and requirement for scalability.  This could apply to CRUD (domains with little domain logic) environments as much as it could apply to highly complex domains.  The fact that a particular CRUD system must deal with terabytes of data may mean the system cannot be implemented without being distributed.  Distribution is often best dealt with through messaging.  That messaging can further be refined by classifying messages as either commands or queries... etc.  The fact that commands in the system encapsulate Create, Update, or Delete operations and Queries encapsulate Read operations doesn't discount the fact that the system inherently requires horizontal or vertical scalability, which is easier done through succinct division of work and communicated through messaging.

The inverse holds true for simple domains.  If I have dozens of commands (and thus dozens events) and queries and we're only dealing with a couple gigabytes of data and commands/queries that might happen once an hour; CQRS is overkill; despite being a complex domain.

This why I don't believe DDD and CQRS necessarily go hand in hand.

The question shouldn't be "does CQRS work with simple domains", it might be "does CQRS make sense for *this* domain".

Cheers -- Peter

--
"Refactoring with Microsoft Visual Studio 2010": http://bit.ly/c13trs
http://PeterRitchie.com/blog/
http://twitter.com/PeterRitchie
http://facebook.com/Peter.Ritchie/
http://www.linkedin.com/in/PeterARitchie
Skype:Peter.a.Ritchie

[Kelly Sommers]

Peter,

Agreed. I think too often "CQRS" is interpreted as a single choice which includes Domain Model and Event Sourcing. I say this a lot, but it reminds me of the MVVM evangelism where everyone assumed they had to do MVVM and it had to include all these patterns we see in MVVM libraries like Event Aggregation etc. It led to a lot of people trying to shoe horn things in and caused more pain than gain.

Each of these pieces should be separate choices with analysis justifying them. They do all go well together but only when your particular problem aligns well with those choices.

Later,

Kell

[Tom Janssens]

By CRUD I assumed the classical MVC model without a real app layer (Controllers accessing the DB directly etc).

In my experience this is quite the opposite of the approach you use with DDD/CQRS.

[Kelly Sommers]

Tom,

Wouldn't the model access the database not the controller?

Later,

Kell

[Peter Ritchie]

MVC is typically a web-based pattern (at least recently).  CQRS isn't limited to web-based front-ends.

But, I would go so far to say that it would be different  to DDD/CQRS because you probably wouldn't be using DDD, just CQRS.

MVC typically means the controller "mediates" between the View and the Model.  And the data access layer "is understood to be underneath or encapsulated by the model".  Most descriptions of MVC don't even mention database.

Cheers -- Peter

On Thu, Jan 26, 2012 at 10:31 AM, Tom Janssens <d4s...@gmail.com> wrote:

By CRUD I assumed the classical MVC model without a real app layer (Controllers accessing the DB directly etc).

In my experience this is quite the opposite of the approach you use with DDD/CQRS.

[sudarshan]

When i say CQRS i picture some thing like
http://codeofrob.com/archive/2011/09/28/cqrs-is-too-complicated.aspx

The model where he talks about using views to project a denormalised
view of your database.

I think its the 4th daigram in the post ..


I am presently not even working in a distributed environment ... and i
have been wanting to know the communities view in using such a
pattern .... Especially in domains which do not need massive scaling
but have a certain degree of inherent complexity/behavior ....

Thanks

On Jan 26, 9:05 pm, Peter Ritchie <pe...@peterRitchie.com> wrote:
> MVC is typically a web-based pattern (at least recently).  CQRS isn't
> limited to web-based front-ends.
>
> But, I would go so far to say that it would be different  to DDD/CQRS
> because you probably wouldn't be using DDD, just CQRS.
>
> MVC typically means the controller "mediates" between the View and the
> Model.  And the data access layer "is understood to be underneath or
> encapsulated by the model".  Most descriptions of MVC don't even mention
> database.
>
> Cheers -- Peter
>

> On Thu, Jan 26, 2012 at 10:31 AM, Tom Janssens <d4sk...@gmail.com> wrote:
> > By CRUD I assumed the classical MVC model without a real app layer
> > (Controllers accessing the DB directly etc).
> > In my experience this is quite the opposite of the approach you use with
> > DDD/CQRS.
>
> --

> "Refactoring with Microsoft Visual Studio 2010":http://bit.ly/c13trs<http://lynk.at/c13trs>http://PeterRitchie.com/blog/http://twitter.com/PeterRitchiehttp://facebook.com/Peter.Ritchie/http://www.linkedin.com/in/PeterARitchie
> Skype:Peter.a.Ritchie

[Tom Janssens]

Kelly & Peter,

Both correct!

Not my day today apparently...

Tom

[Peter Ritchie]

So, if you're not segregating your read and your write database, why do you think you're doing CQRS? Is it just the denormalization?

If we assume that one possible deployment of CQRS is that the read and the write database are not segregated; what benefits to you see coming from this?

Let's assume that the benefits have to be over and above what Command Query Separation principle would give you...

Curious -- Peter

[sudarshan]

I am not sure about the terminology here, the blog post I showed above
mentions it as cqrs, maybe its something more like cqs ....

I think just separating out the read from writes itself is a good
first step ...especially for simpler projects which do not run in a
distributed environment ...


So according to you cqrs implies having separate physical data
stores ?

> >http://PeterRitchie.com/blog/http://twitter.com/PeterRitchiehttp://fa...

[Nuno Lopes]

HI,

MVC is typically a web-based pattern (at least recently).  

Actually is quite the contrary. It was never a web based patter, just a pattern.

Having said this:http://codefish21056.blogspot.com/2010/08/cqrs-mvc.html

[ashic]

CQRS refers to having the responsibilities of commands and queries
segregated - i.e. they should be not be done by the same thing. Using
two separate stores is an option but not necessary.

> > "Refactoring with Microsoft Visual Studio 2010":http://bit.ly/c13trs<http://lynk.at/c13trs>http://PeterRitchie.com/blog/http://twitter.com/PeterRitchiehttp://fa...
> > Skype:Peter.a.Ritchie

[Nils Kilden-Pedersen]

On Sat, Jan 28, 2012 at 4:46 PM, ashic <ashic....@gmail.com> wrote:

CQRS refers to having the responsibilities of commands and queries
segregated - i.e. they should be not be done by the same thing. Using
two separate stores is an option but not necessary.

I am, like most people it appears, struggling to properly delineate what CQRS is. Even Greg and Udi seems to disagree on some points, and I've seen Greg argue the point you're making, which makes sense to me. 

However, take for example your average PHP application. It's basically as flat an architecture as you can get. The SQL is executed directly in the page itself, and so are updates. Could one argue that to be CQRS? That is the only problem I have with Greg's argument that it can even be the same data store. The argument makes perfect sense in an ORM setting, where using the same data store, but separating the object model, is an obvious win. But when not dealing with an ORM model, it's less clear and I would really hate to say that people coding PHP is doing CQRS.

[Philip Jander]

> I am, like most people it appears, struggling to properly delineate
> what CQRS is. Even Greg and Udi seems to disagree on some points, and
> I've seen Greg argue the point you're making, which makes sense to me.
>
> However, take for example your average PHP application. It's basically
> as flat an architecture as you can get. The SQL is executed directly
> in the page itself, and so are updates. Could one argue that to be
> CQRS? That is the only problem I have with Greg's argument that it can
> even be the same data store. The argument makes perfect sense in an
> ORM setting, where using the same data store, but separating the
> object model, is an obvious win. But when not dealing with an ORM
> model, it's less clear and I would really hate to say that people
> coding PHP is doing CQRS.
>

There seems to be an increasing amount of topic added to "cqrs".
So far, my personal definition (based IIRC on one of Greg's conference
talks) was "two models where previously was only one", one optimized for
transaction and one for read/query access, where the second model is a
deterministic function of the first.
You can do that with PHP, no problem :)

Cheers
Phil

[Greg Young]

Thats more of a distinction than I make...

--
Le doute n'est pas une condition agréable, mais la certitude est absurde.

[Nils Kilden-Pedersen]

On Sun, Jan 29, 2012 at 2:58 PM, Philip Jander <jan...@janso.de> wrote:

There seems to be an increasing amount of topic added to "cqrs".

So far, my personal definition (based IIRC on one of Greg's conference talks) was "two models where previously was only one", one optimized for transaction and one for read/query access, where the second model is a deterministic function of the first.
You can do that with PHP, no problem :)

I didn't mean to say that you couldn't do CQRS with PHP, but rather if the average PHP app should be considered CQRS, because the reads are separate from the writes?

 

Cheers
Phil

[Peter Ritchie]

Well, I think there's a distinction about a particular deployment of an architecture and whether or not it can't be deployed distributed.

Any CQRS implementation where the read and write databases use the same /type/ of data can obviously be on one machine that shares a database instance.  I wouldn't necessarily say this isn't CQRS; but, if that's you intended deployment, what benefits to you hope to gain from CQRS?

CQRS gives you huge decoupling benefits.  For example if you separate reads from writes, one shouldn't influence the other.  (typical reporting example is someone does a huge report and because the write database is somewhere else, the application isn't impacted).  If the read/write databases are in the same DB instance, that influence gain is lost.

Cheers -- Peter

[Peter Ritchie]

"Web-based" was a poor choice of words.  A pattern used primarily on the web...

MVC works  very well on the web because the controller is typically responsible for handling input events (actually, if the controller isn't doing that, then it's probably not MVC)...  This is great with web because you're stateless, when you get a input event you don't have a view yet; so it goes right to the controller and it's responsible for doing something with a view, if it needs to.

Client applications, on the other hand, typically the UI is the view and all input events go through the UI (and thus the view).  With MVC this kinda means the View tells the controller about input and then waits for the controller to tell it to do something about that input.  Still MVC, and may give you lots of benefits as a pattern; but tends to get tedious to many devs having this circular communication get anything done.

But, I digress... :)

Cheers -- Peter

[Craig Wilson]

I think much of the benefit of CQRS lies in the business value inherent in the domain portion of the project, not necessarily the different storage implementations.  Albeit, I usually have seperated read and write stores, but CQRS doesn't require that.  The data store is largely an implementation detail  I can distill the same data store into a write model and read model at the same time, making the benefit to be driven by the behaviour of each of those models rather than the data store underneath.

[Nuno Lopes]

Hi,

Again, actually its quite the contrary. MVC was designed to work initially in a fat client environment quite successfully (long before the web). 

Original MVC implementation input was handled directly by the controller not the view as you mention, that in turn makes changes to the model and might instruct the view refresh or assume some other state. In some scenarios the view is notified directly by the model by subscribing to model events. The workflow is quite similar to CQRS.

Now, it may be the case where you used a particular fat client UI framework that implemented a variation of MVC in the way you described.

On the web, say in the last 8 years or so, as Web Apps got fatter and web app frameworks got more mature, MVC started to be a more feasible pattern to be used in Web Apps-

Initially the concept of controller I believe  got diluted by auto generating view event handlers in a lot Web Frameworks including for instance ASP.NET. Which basically leads to the design you mention where the controller is optional and if one exists is then called by these handlers. But lately with advances such as REST and AJAX the controller is becoming more and more explicit in a web ui.

Cheers,

Nuno

[Peter Ritchie]

If you don't have separate read and write stores, what does "segregated" me to you?

I'm honestly curious about these types of deployments.  I'm trying to figure out what the perceived benefits are to a deployment that isn't truly segregated.  i.e. over and above CQS, what do you hope to benefit from CQRS?

Cheers -- Peter

On Mon, Jan 30, 2012 at 12:18 PM, Craig Wilson <craigg...@gmail.com> wrote:

I think much of the benefit of CQRS lies in the business value inherent in the domain portion of the project, not necessarily the different storage implementations.  Albeit, I usually have seperated read and write stores, but CQRS doesn't require that.  The data store is largely an implementation detail  I can distill the same data store into a write model and read model at the same time, making the benefit to be driven by the behaviour of each of those models rather than the data store underneath.

[Greg Young]

Separating just to not push writes through domain but to use
materialized views etc can be rather useful in many cases.

--

[Craig Wilson]

Oh, I agree.  I always separate the stores.  However, I'm just saying that it isn't a requirement and that the main benefit of CQRS (for me and my team) was the behavioral aspects of it.  The optimized read and write data stores were just an extra benefit.

[Peter Ritchie]

Agreed.  But, you could say that's simply use of DTO and abiding by basic stability and layering principles.  I'm not sure that's a CQRS differentiator...

Having materialized views sounds a lot like First Law of Distribution--but, we're getting back to distribution.

Does it make sense that "segregation" in CQRS means segregation via distribution?

Cheers -- Peter

[Peter Ritchie]

The basic architecture definitely facilitates physical separation of databases.

Speaking of the optimized reads/writes; are you taking that a step further and separating reporting out of the mix into something like BI warehouses?

Cheers -- Peter

On Mon, Jan 30, 2012 at 3:52 PM, Craig Wilson <craigg...@gmail.com> wrote:

Oh, I agree.  I always separate the stores.  However, I'm just saying that it isn't a requirement and that the main benefit of CQRS (for me and my team) was the behavioral aspects of it.  The optimized read and write data stores were just an extra benefit.

[Craig Wilson]

We have highly normalized data store to satisfy some political pressures.  The BI guys use this to build OLAP cubes and what not.  Our read stores are usually in MongoDB.

[Jörgen Andersson]

Hi,

Some time ago I wrote a couple of blog posts on the DDD-part of this question.

http://se-thinking.blogspot.com/2011/10/is-domain-driven-design-always.html
http://se-thinking.blogspot.com/2011/10/value-of-using-domain-driven-design.html

Jörgen

Den 23 jan 2012 08:28 skrev "sudarshan" <sudar...@gmail.com>:

[ashic]

@Tom:
Separate models need not necessarily mean separate data models :)

@Peter:
Even if you don't have "segregated storage", handling changes through
monadic composable handlers can reduce coupling and make adding cross
functional & infrastructural concerns easier. Having a separate direct
query interface to the data can also make querying simpler.

[I'm not saying all CQRS apps should use the same data store, but that
just because you use the same store doesn't mean you can't do CQRS]

On Jan 30, 8:40 pm, Peter Ritchie <pe...@peterritchie.com> wrote:
> If you don't have separate read and write stores, what does "segregated" me
> to you?
>
> I'm honestly curious about these types of deployments.  I'm trying to
> figure out what the perceived benefits are to a deployment that isn't truly
> segregated.  i.e. over and above CQS, what do you hope to benefit from CQRS?
>
> Cheers -- Peter
>

> On Mon, Jan 30, 2012 at 12:18 PM, Craig Wilson <craiggwil...@gmail.com>wrote:
>
> > I think much of the benefit of CQRS lies in the business value inherent in
> > the domain portion of the project, not necessarily the different storage
> > implementations.  Albeit, I usually have seperated read and write stores,
> > but CQRS doesn't require that.  The data store is largely an implementation
> > detail  I can distill the same data store into a write model and read model
> > at the same time, making the benefit to be driven by the behaviour of each
> > of those models rather than the data store underneath.
>
> --

[João Bragança]

@ashic:
IOW, ORM for the write side and direct sql connection on the read side :)

[Peter Ritchie]

I'm willing to concede on "segregated storage" and accept that a CQRS implementation supports segregated storage in that whether or not storage is actually segregated is a configuration detail.

I think your mention of monadic decomposition is very important.  I haven't seen this explicitly stated before.  I think it's very important for messages, and thus commands and events, to be as "atomic" (e.g. monadic) as they can be and still have meaning in the domain.

Simplifying things down to the smallest possible tasks offers the greatest decoupling, greatest cohesion, and the greatest flexibility in how you schedule and distribute the tasks.  Where a task is something that processes a message.

Cheers -- Peter

[ashic]

While decomposition is definitely a very good thing, I was referring
to composition of handlers (which are monads - single argument
methods). Something like:

var someHandler = new SomeCommandHandler().Handle;
var loggerWrappedHandler = new LoggingHandler(someHandler).Handle;
var transactionalHandler = new
TransactionalHandler(loogerWrappedHandler).Handle;

bus.Register<SomeCommand>(transactionalHandler);

In an MVC app for example, the controller can then simply take in an
IBus and dispatch commands by bus.Send(command);

Cross functional infrastructural requirements are then kept entirely
in the composition root and it becomes much easier to support OCP and
SRP. AOP, IoC etc. without any weird magic - just one composition
root. It's a benefit of using the command pattern rather than CQRS but
it is one of those selectable thngies that you get to pick and choose.

[Peter Ritchie]

I think that's oversimplifies monads slightly...  I could take an existing code base and simply perform introduce parameter object refactoring on all methods and have all "monadic" methods.

Introducing an application-controlled way of invoking those methods (like a bus and calling them "message handlers") and you get only trivial AOP, decoupling, and cohesion.  The fact that you can now compose handlers doesn't presuppose you can realistically get all your cross-functional requirements out of your message handlers.  Take a 1000 line message handler for example.

I think there's much more to a "monadic" design than just performing introduce parameter object refactoring and introducing pipelining.  You also have to decompose the system to get irreducible message handlers from the aspect of the domain.  Maybe "monadic" is just a bad choice of words for that concept.

Irreducible, or atomic, domain message handlers (and thus more granular SRP) introduce more cohesion and decoupling benefits that help with understanding, maintainability, parallelisability, ability to distribute work, etc.  These are the benefits I see from a message-oriented architecture like CQRS.

So, in effect I'm saying that for a message-oriented architecture it's more important to apply good object-oriented design and analysis techniques. That could mean DDD, GRASP, Functional-Class Decomposition, etc...

Cheers -- Peter

--
"Refactoring with Microsoft Visual Studio 2010": http://bit.ly/c13trs

[ashic]

Completely agree...

1000 line command handlers would suggest something quite wrong
somewhere. My point was that composing the pipeline and functional
decomposition are both benefits of commands.If the pipeline
composition becomes really complex, chances are there's some
functional decomposition to be done.

[andho]

Does the reads use a separate model from the writes? If yes, then it's CQRS.

[andho]

Segregated means separate read MODEL and write MODEL, not datastore.

[Peter Ritchie]

I think that's a fairly accurate distillation...

[sudarshan]

Thanks ... This clears up the confusion around the terminology at
least for a newbie like me :)

[Nils Kilden-Pedersen]

On Tue, Jan 31, 2012 at 2:40 PM, João Bragança <joao...@braganca.name> wrote:

@ashic:
IOW, ORM for the write side and direct sql connection on the read side :)

Doing ORM on the write-side, doesn't that force you to expose all the data, breaking encapsulation?

[John Thornborrow]

No. Just don't expose your ORM'd classes. 

[Nils Kilden-Pedersen]

Funny, I was thinking that shortly after I wrote it.

[Rob Ashton]

Or just use conventions to map private state