stooboo.com

Bear with me, this is just a holding-post to list some things that I want to come back to.

It's going to get a bit waffly from here, but that's while I work out what I want from CQRS and DDD, and more importantly how I can leverage them in my code !

As I understand it ..

• CQRS is rising in popularity
• CQRS is NOT event sourcing
• CQRS can be applied gradually to your current programs
• Implementing CQRS will (hopefully) allow you to do other things in the future e.g. event sourcing
• • It'll encourage you to write 'task-based' or 'inductive' UIs rather than 'deductive' UIs

• Domain objects should NOT have getters or setters
• • This seems really strange but ..if you have getters then someone somewhere will write logic outside your domain object based on the state of that domain object (you can't necessarily prevent that, but you want to minimize it)
• Domain objects are about BEHAVIOUR and not STATE
• • if you have a domain object with loads of properties and no methods then it's a Anaemic Domain Object.. this is bad … where is the behaviour (i.e. all those methods ?) .. in services? .. tied up in code-behind on a website or in WPF ?  .. BAH !!!
  • Not everyone (every class) wants to know the same things about an object's state… so when we do present state outside of a domain object there many be many 'representations' of that state .. but ALL of them should be considered read-only

Sources

• http://martinfowler.com/eaaDev/DomainEvent.html
• http://codebetter.com/gregyoung/2010/04/11/what-is-a-domain-event/
• http://lostechies.com/jimmybogard/2010/04/08/strengthening-your-domain-domain-events/
• http://elegantcode.com/2009/11/20/cqrs-the-domain-events/
• http://elegantcode.com/2010/01/06/event-driven-architecture-publishing-events-using-an-ioc-container/
• http://blog.robustsoftware.co.uk/2009/08/better-domain-event-raiser.htmlhttp://www.agilification.com/?tag=/CQRS
• http://www.codinginstinct.com/2011/04/queries-aggregates-ddd.html
• http://msdn.microsoft.com/en-us/library/ms997506.aspx