Reliable CQRS "framework"... new member of this great group

[Jose Fernandez]

Hello guys,

thank you for this group. Much needed.

I am very sold on CQRS and DDD. I have done a couple of projects, small-garage-projects, and i feel pretty comfortable I can switch over this "principles" for my future projects.

This is the deal. I am in charge of a large application ( i didn't create it), that runs the business almost decently, but i want to make it better because it's on the verge of collapsing (SQL 2000 + Access 2010 front end application). This domain (medical billing + patient care + accounting + integrated marketing domain) has a lot of potential for DDD and CQRS.

I have read in different blogs to stay away from such called CQRS Frameworks... since there's an argument that CQRS can't be converted into a framework per se. However i find useful the fact that a lot of repetitive task can be abstracted "as a" framework and use it.

My question... is there any framework out there (that does not force me to use Azure, thanks, but no thanks), that is not going to blow on my face after this project gets heavier and bigger?

I took a look at NCQRS... seems to me a little over engineered.. am i wrong? Looks like one of those super-flexibles, suited-for-everyone Microsoft's monsters.

Any input on this? Do i really need a framework? or with a good set of good practices is enough?

Thanks in advance

[Greg Young]

What this are you looking for a framework to do for you?

--
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/groups/opt_out.
 
 

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

[Jose Fernandez]

Hello Greg,

Well, that's where i am a little confused. I've been reading a lot of stuff.

I am looking for a DDD-CQRS-RDBMS approach to build a couple of new projects. (i can't go event sourcing thou. This client loves his database. as a matter of fact all his domain is literally built on stored procedures)
I guess what i need is some base infrastructure (all the wiring, interfaces, abstract classes, generic stuff). I was looking at your simplecqrs demo which i think is pretty straight forward. Of course, I am new in the whole cqrs thing so i wouldn't know how to identify which of all the approaches i have found is really a good fit for medium to large projects.

That's pretty much the bottom line of my original question. I guess i need to understand all the concept a little bit more before I make a decision, but i get paid to make things happen, not to do research. Like you said in one of your articles, a working software is worth thousand times more than the "built right" sitting in your "Lab" folder.

What's your opinion?

Thanks

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

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

[Jose Fernandez]

http://cqrssample.codeplex.com/

maybe something like this...

but of course, one that has been tested and if possible, in production.

On Sunday, May 12, 2013 10:14:04 PM UTC-4, Greg Young wrote:

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

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

[@neilbarnwell]

I'm not entirely sure a "CQRS" framework would help. CQRS is just a style or guideline, that, if followed, allows you to do other things. I have a library called Regalo that I wrote and am using in production but that actually is more about event sourcing and helping offer a style of writing domain objects in such a way to enable event stream merging etc. The CQRS-nature of a given app is really just how you assemble it. Command/Query Responsibility Segregation is what it says - segregating the things responsible for doing those things, such that they can differ in interesting, useful, scalable etc ways.

[Greg Young]

I'm considering packing up a set of related gist frameworks of things like aggregate bases w/wo unit of work. Examples of command handler wiring etc. not really a framework though more code people can take. Might this be valuable to anyone?

--
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/groups/opt_out.
 
 

[Neil Barnwell]

That is basically the idea of Regalo - one could just use it for inspiration (I took a lot of ideas from you course to build it) or use it as-is. I have a partial demo project called Vita on github to go with it as a sort of sample implementation. Have a look at that and let me know what you think? Happy to accept feedback if it's not too heavy-weight for your purposes?

Neil Barnwell.
Mobile: 07900 221457
Twitter: @neilbarnwell
e-mail: mai...@neilbarnwell.co.uk
web: http://www.neilbarnwell.co.uk

You received this message because you are subscribed to a topic in the Google Groups "DDD/CQRS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dddcqrs/wB6ZWP9O6m4/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to dddcqrs+u...@googlegroups.com.

[Greg Young]

I'll check it out tomorrow.

[Neil Barnwell]

Cool. To save you searching: https://github.com/nbarnwell/Regalo and https://github.com/nbarnwell/Vita.

Be gentle. :)

Neil Barnwell.
Mobile: 07900 221457
Twitter: @neilbarnwell
e-mail: mai...@neilbarnwell.co.uk
web: http://www.neilbarnwell.co.uk

[Jose Fernandez]

Hello Neil. Totally agree with you and i am pretty aware that there's no such a thing like CQRS Framework.

I have to be honest, Event Sourcing seems "pretty cool" but it's not practical for me, for example, the majority of my contracts, they ALWAYS involve legacy code, legacy normalized databases, etc.

If anyone here has ever been involved in migrating/converting legacy software to newer technologies, you know you just can't cut off the old system and bring a new one. Such a thing does not exist because the business needs to keep running.... otherwise you won't get paid :). At this point you know the best strategy is to build it parallel to what is in production (mostly because of data) and use the current data scheme/structure until you've taken over and THEN you can start making some database adjustment if really needed.

That's my approach in my projects, have worked for me and clients are very happy.

For that reason i really don't look into Event Sourcing too much, because i know for a fact i will not be using it, or it's just not practical for me.

Have you checked DDDSample? This guy has a Shipping project and he showed different approaches using different alternatives. Pretty good in my opinion.

Can i take a look to your Regalo?

Thanks

[Jose Fernandez]

Hello Greg,

I strongly believe that if YOU prepare (if I do it probably nobody would use it) sort of a core library with all of those base requirements for CQRS + DDD + DATA STORAGE (SQL, RavenDB), then add some optional modules to it for Event Sourcing with SQL, RavenDB (just to mention two different types of DB), add modules for IOC, modules to use it with or without WCF or REST, etc. If you do that, you would help the community ENORMOUSLY. I think you can start with your SimpleCQRS project and go from there. FakeBus would be NService or Azure or whatever other module you add to it. Bullshit Database would be a SQL or RavenDB module. Etc, etc.

As a matter of fact, you could give it out FREE if you want, but i would pay for it, and i am talking 3 figures no problem.

I am pretty sure you will draw so many awesome programmers in the community to collaborate with you...

What do you say?

On Sunday, May 12, 2013 10:14:04 PM UTC-4, Greg Young wrote:

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

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

[Tom Janssens]

For the record; I have implemented "umphteen" CQRS frameworks and published like 5 or 6 on my github account before I finally realized that the infrastructure implementation is the easy part, I now prefer to evolve the implementation as required, and usually start off with a few interfaces.

It is a pattern, a way to write code; whether you do it with event-sourcing or simple interfaces does not matter. The infrastructure is the easy part; modelling your domain is the hard part...

Op maandag 13 mei 2013 02:34:36 UTC+2 schreef Jose Fernandez het volgende:

[Gabriel Schenker]

I have to say that Tom hit the nail! I have experienced exactly the same... the framework is the easy part. Doing the domain "right" can be and is most of the time challenging.

You can use the most sophisticated CQRS framework out there and do your domain wrong and the result is a mess (believe me, I have gone through that!) or you can invest more time in a careful design of the domain and the infrastructure becomes an after thought since it is so evident and simple what you have to do.

Specifically if you use an event store like GetEventStore nearly all the hard infrastructure work is already done. And if you use MongoDB or RavenDB for the read model their respective plug-in is super easy.

--
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.

[Greg Young]

I think the point is missed here. I will not make all those. I will provide infinitely fork able (no pull request) gists. How you deal with persistence is very specific to your app. Abstraction hurts here.

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/groups/opt_out.
 
 

[Jose Fernandez]

By the way Neil, "Regalo" in spanish means Gift... but not just a gift, like a Precious Gift. Maybe the universe is working with you inadvertently.

I took a look at it and I like it. Seems concise. Not junky which is good. Greg should be proud of you :). I will be waiting for his review.

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

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

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

--
You received this message because you are subscribed to a topic in the Google Groups "DDD/CQRS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dddcqrs/wB6ZWP9O6m4/unsubscribe?hl=en.

To unsubscribe from this group and all its topics, send an email to dddcqrs+unsubscribe@googlegroups.com.

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

--
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+unsubscribe@googlegroups.com.

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

[Greg Young]

We are looking at making this easier btw. What if from js you could say kv-storage-update(key, Val) from js? Or neo_add_rel(node1,node2, real type)

[Dennis Traub]

CQRS is easy if not trivial. DDD is hard: it promotes (and requires thinking). No framework can do the thinking for you. I appreciate you trying to follow the Shu-Ha-Ri approach but still a framework whatsoever will be of no help at all. If you want to learn about CQRS (and DDD) then you might want to seek out an OSS project you can contribute to.

--
Dennis Traub
Software Development Consultancy

Am Bogen 7
33178 Borchen

Phone:  05293/73942-73
Fax:    05293/73942-74
Mobile: 0170/2842385
Mail:   ma...@dennistraub.de

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

[Greg Young]

+1 however cqrs and es in particular changes many things in ddd.

--

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/groups/opt_out.
 
 

[Gabriel Schenker]

but IMHO makes it a bit more approachable. The concept of BCs and Aggregates and (business-) transaction boundaries become more explicit...

[Phil]

Agree.  James, Yves, myself all have AggRoot gists(I think).  I found it much easier to piece the gists together (AggRoot, ImMemBus, EventDispatcher, etc) for a project.  I keep the read model interfaces the same as the API I am using (Raven, Redis, etc.)

Here is an Agg Root gist.  I use strongly typed events because I like that, but some others prefer object.  Just one of the differences that is hard to deal with in a framework, but is easy with a gist.

https://gist.github.com/pdoh00/4658759

Phil

@pdoh00

Phil

[Jose Fernandez]

I wasn't talking about Domain-Thinking-From-a-Framework.... kind of thing. Programming Welfare? :)

I was trying to save some time with trivial stuff (infrastructure). I can grasp the concept of CQRS. Not a problem. Greg Young made it easy with his SimpleCqrs... however, i know that there should be some "base" work already out there that would save me some time and focus on the domain side of the application. That's it.

[Wim van Gool]

Jose, if you're still looking for a 'framework' that just takes off the burden of some infrastructural concerns, you might want to take a peek at the MessageProcessor lib I've been working on. It was mainly started as a private project but then I refactored parts bit by bit into this library as I was (and still am) implementing some DDD-practice projects. You can take it off NuGet or download the sources from GitHub.

What I've tried to do here is to refrain from implementing all sorts of base classes or interfaces for CQRS/DDD-specific stuff, but just provide a means to declare message handlers (for internal and external messages), have them automatically registered (if you want to), and then just go implement the logic anyway you like. The main extra's are the DomainEventBus to publish domain events the way Udi proposed and that it has a built in mechanism to dynamically register your infrastructure-classes to a UnitOfWorkManager (by injecting an instance of this type and call _manager.Enlist(this) or something), so that they'll be flushed when the request has succecfully completed (much like that ADO.NET TransactionScope pattern).

The only problem is that I haven't gotten to documenting it well yet or put a finished sample-project online, but a intend to in the near future. Feel free to ask me any questions if you tend to try it out though.

On Mon, May 13, 2013 at 6:50 PM, Jose Fernandez <ppc...@gmail.com> wrote:

I forgot to mention... i wish i had time to contribute to one of those projects. But i barely have time to shave in the mornings. I don't even have an account on Github. i'd rather pay for a stable, tested piece of code, than venturing into the discovery journey. Business unfortunately brings that reality check. :( I wish i could because i enjoy my career, but anyone that is involved in large projects with fat greasy investors breathing on your neck, know very well that in those environment there is barely room for nothing, and zero tolerance for blue screens.

On Monday, May 13, 2013 12:15:33 PM UTC-4, Dennis Traub wrote:

[Neil Barnwell]

+1. Regalo has an AggregateRoot base class you can use, but also has interfaces and impl for a command processor and event bus (both basically the same but the intent is clearly different). You can [install-package regalo.core] and just use those bits if you need them. The more you choose to use the more opinionated it gets, basically.

Neil Barnwell.
Mobile: 07900 221457
Twitter: @neilbarnwell
e-mail: mai...@neilbarnwell.co.uk
web: http://www.neilbarnwell.co.uk

[Jose Fernandez]

William, thank you for your response. I will take a look at it. I was looking at Regalo's framework and seems very clean and simple. Most of the code i have found is very convoluted and unnecessary in my opinion. Seems like the developer wants to make a statement :) which is good because it keeps them motivated.

But i will definitely take a look at your stuff.

[Jose Fernandez]

@Neil,

I am going thru your code. I noticed something, please, correct me if i am wrong.

Are you treating Domain Services as aggregateRoots?

I am talking about FundsTransfer:AggregateRoot

This aggregateRoot looks to me like a Domain Service.

I can see why you are doing this, which makes me wonder... Does Domain Services disappear with CQRS?

I am asking because FundsTransfer is the classic example of a DomainService where they are stateless and mostly statics. They just perform an action between two (or more) aggregates... in order to prevent an aggregate to modify other aggregates' states.

Thanks.

[Neil Barnwell]

The funds transfer is more of a saga, really. Many aggregate roots will end up acting as a state machine, and sagas in this sense are a specialised style of state machine that coordinate messages between other aggregates over multiple transactions.

The idea is that because any given command is one transaction, you can't modify two aggregates (destination and source accounts). The idea is you set up an object (in this case the FundsTransfer) that emits events that are handled downstream and responded to. When the responses come back the FundsTransfer can do the next operation and so on.

Tbh it's not always necessary to adhere to the perfect world of one-transaction-on-one-aggregate-per-command rule, you could just use distributed transactions if you have low throughput. This was deliberately over-engineered in a sense to demonstrate how you'd implement a saga with Regalo.

Neil Barnwell.
Mobile: 07900 221457
Twitter: @neilbarnwell
e-mail: mai...@neilbarnwell.co.uk
web: http://www.neilbarnwell.co.uk

[Jose Fernandez]

Hmmm, i see. Now, what's the FundsTransferSaga class for then?

I am still going thru your code. At this point i realized is heavier in the Event Sourcing, than the CQRS. I don't really need Event Sourcing but your code seems very clean and concise which is good. Did you check the issue i posted on your Vita github?

Have you checked this http://dddsamplenet.codeplex.com/SourceControl/latest ?.

[Neil Barnwell]

Oh man I can't remember which way round it is now. One is an aggregate, the other is an application service I think. Yes, as I said, Regalo is more about event sourcing though it has a few things and encourages a style that makes CQRS easier. Because the possibilities of CQRS are literally infinite, any CQRS framework is really just constraining you. Regalo will allow you to get events out of a domain and use them for persistence, if you send them to something that updates a db, great, but you could send them to something that writes HTML files out to disk or calls into a NodeJS server or literally anything else you can imagine. :)

Neil Barnwell.
Mobile: 07900 221457
Twitter: @neilbarnwell
e-mail: mai...@neilbarnwell.co.uk
web: http://www.neilbarnwell.co.uk

[Neil Barnwell]

I did get an email from Github, yes. Thanks for the feedback. :) I'll take a look.

Neil Barnwell.
Mobile: 07900 221457
Twitter: @neilbarnwell
e-mail: mai...@neilbarnwell.co.uk
web: http://www.neilbarnwell.co.uk

[Neil Barnwell]

So the FundsTransferSaga is just another application service (which in Vita means it's an event handler). The current impl isn't finished yet which probably doesn't help with understanding. I'll see if I can get some of it done now and push so it makes a bit more sense.

[Jose Fernandez]

I wanted to say Thank You for your responses. Specially Neil and Greg.