An Introduction To CQRS

Introduction to CQRS Approaches to System Architecture @NeilRobbins neil@computer.org

Tonights show is brought to by the following #tags #cqrs #glnet Hopefully not #fail, #WTF, or #WasteOfTime

What are we going to cover? Overview of the space CQS, Commands, Queries, DDD Simple CQRS Distributing CQRS Events Pub-Sub Eventual Consistency & Conflict Management Event Sourcing & CQRS What & Why? Some Code – Phew!

An interface should be attractive! ,[object Object]

Command-Query Separation Principle Asking a question should not change the answer From: Object-Oriented Software Construction, 2nd Edition by Bertrand Meyer

Command-Query Separation Principle public interface IAmACqsExample { void DoSomething(); void DoSomething(Argument arg); Result GetSomething(); Result GetSomething(Argument arg); }

So what is CQRS? Started out as: DDDD (Domain Driven Design + Distributed) Architectural CQS Now: Command Query Responsibility Segregation

So what is CQRS? – Part Deux A trinity Commands Queries Intent capturing UI

Simple CQRS Façadelient Logically distributable Commands Fully Consistent Queries

What does a command look like? CreateAnOrderForTheCustomer ,[object Object]

Clearly represent client intent

Highly likely to succeed,[object Object]

CQRS Meets DDD But it doesn’t have to Core domain, supporting domains Need not be everywhere, some can be transaction script with Anaemic objects Ubiquitous language can lead to a clean interface Organising by aggregate root can make for simpler persistence Domain object should never be put in an invalid state!

Domain Objects: Forget Properties! public class Event { public string Name { get; set; } public int Venue { get; set; } public DateTime Date { get; set; } public IEnumerable<Session> Sessions { get; set; } } public class Session { public PresentationPresentation { get; set; } public string Location { get; set; } public DateTime Time { get; set; } }

Domain Objects: No Queries No Queries on your domain objects! Yes, that definitely includes any getters! Nada! (well maybe one, we’ll see that much later) All querying will be done through the Query system No binding to domain objects

Domain Objects: Control your mutations Only Command methods exposed They don’t return things either! Controlled mutation of state Ensures that aggregate roots do not enter into invalid states Ever! No IsValid() method (it’d be a query anyway)

So what about Queries? They’re just queries They support the UI which should provide a Decision Support System Get quickly from the database Immutable objects

Intentful UI Shopping Cart Service Command Command Ratings Service Command Command Product Images Service Command Command Command Buying Choices Service Offers Service Bought Together Service

Intentful UI Captures Intent Aligns with commands Want to know WHY something changed, not just that it did Decide on an appropriate level of granularity, what’s important to your client/business? Customer address changed Or Customer moved house Or Customer’s address was incorrect

Intentful UI Uses the query infrastructure For display For decision support Should be a pit of success Commands should succeed Will contain logic, is typically rich

Distributing CQRS Introduces some issues Keeping things in sync Faults become more likely Can give some wins Availability Scalability May/Should make some choices CAP Theorum

Introducing Events Something happened Past-tense Capture the details of the change Simple immutable data-structures Can be fed into MapReduce jobs Can be consumed more widely across the enterprise Integrate with other systems Send emails Update DataMarts/Warehouses

Façadelient Bus Commands Eventually Consistent Queries Handler

Keeping the Query Side in Sync Don’t have to forego Consistency Can perform 2 Phase Commits Can use quorums But there’s a price in the face of a fault write performance will degrade restrictive in the face of wide-geographical distribution Can use: RDBMS crazyness ;) PubSub

Subscriber Subscriber Publisher Subscribers Subscriber

Event Sourcing …there are times when we don't just want to see where we are, we also want to know how we got there http://martinfowler.com/eaaDev/EventSourcing.html 2 Ways to persist changes Snapshot of current state Just the change itself

ID : 123 Name : The Art of War Author: Sun Tzu ISBN: 1234ABCD5678 Event: BookIsbnChanged NewValue: 4321DCBA8765

Time to See Some Code You didn’t think I’d make you watch me type did you? A small taste of Greg Young’s course (with minor changes) – link at the end.

First up a domain object namespaceProgNetDemo { public classCatalogItem { } } The domain object

A Command Method namespaceProgNetDemo { public classCatalogItem { public void Retire() { } } } Now we add a behaviour

Some State To Change namespaceProgNetDemo { public classCatalogItem { privatebool _retired; public void Retire() { } } } Some state that will need to be mutated

Guard the Mutation namespaceProgNetDemo { public classCatalogItem { privatebool _retired; public void Retire() { if (!_retired) thrownewInvalidOperationException(); } } } Protect the validity of the object!

Make the State Mutation A Domain Event namespaceProgNetDemo { public classCatalogItem { privatebool _retired; public void Retire() { if (!_retired) thrownewInvalidOperationException(); ApplyEvent(new RetiredEvent(_id)); } } } State mutations are a 2 phase activity

Need an Identifier for the Aggregate public classCatalogItem { privatebool _retired; privateGuid_id; public void Retire() { if (!_retired) thrownewInvalidOperationException(); ApplyEvent(new RetiredEvent(_id)); } } The event needs to know the Id of the Entity being updated

Create the Event publicclassRetiredEvent { privatereadonlyGuid _id; publicRetiredEvent(Guid id) { _id = id; } } Don’t need more state, in this case the name says it all Note it’s immutable

Need to be Able to Apply the Event public classCatalogItem { privatebool _retired; privateGuid_id; public void Retire() { if (!_retired) thrownewInvalidOperationException(); ApplyEvent(new RetiredEvent(_id)); } } Still need to write the code to apply the event.

Create a Base Class public abstract classAggregateRoot { protected voidApplyEvent(Event @event) { } } All Aggregate Roots will extend this class We’ll need to handle more than just the one type of event!

Create the Event Type public classEvent { } Would want to move the AggregateId into this base class

Have our RetiredEvent Inherit From the Base Type publicclassRetiredEvent : Event { privatereadonlyGuid _id; publicRetiredEvent(Guid id) { _id = id; } }

Still Need to Mutate the State public classCatalogItem : AggregateRoot { privatebool _retired; privateGuid_id; public void Retire() { if (!_retired) thrownewInvalidOperationException(); ApplyEvent(new RetiredEvent(_id)); } }

Create a Method to Handle the State Change From the Event public classCatalogItem : AggregateRoot { privatebool _retired; privateGuid_id; public void Retire() { if (!_retired) thrownewInvalidOperationException(); ApplyEvent(new RetiredEvent(_id)); } private voidApplyRetiredEvent(RetiredEvent @event) { _retired = true; } } This method will actually apply the event, that is mutate the state

Done!? public classCatalogItem : AggregateRoot { privatebool _retired; privateGuid_id; public void Retire() { if (!_retired) thrownewInvalidOperationException(); ApplyEvent(new RetiredEvent(_id)); } private voidApplyRetiredEvent(RetiredEvent @event) { _retired = true; } }

Need to Connect the Event with the Handler public classCatalogItem : AggregateRoot { privatebool _retired; privateGuid_id; publicCatalogItem() { RegisterHandler<RetiredEvent>(ApplyRetiredEvent); } public void Retire() { if (!_retired) thrownewInvalidOperationException(); ApplyEvent(new RetiredEvent(_id)); } private voidApplyRetiredEvent(RetiredEvent @event) { _retired = true; } } This could be done following a convention instead Note, this is the specific Event subtype – more later!

Allow Handlers to be Registered public classAggregateRoot { protected voidRegisterHandler<TEvent>(AppliesEvent<TEvent> handler) whereTEvent : Event { } protected voidApplyEvent(Event @event) { } } The delegate signature needs to be defined

Create the Delegate Signature public delegate voidAppliesEvent<TEvent>(TEvent @event) where TEvent : Event; public classAggregateRoot { protected voidRegisterHandler<TEvent>(AppliesEvent<TEvent> handler) whereTEvent : Event { } protected voidApplyEvent(Event @event) { } }

Need to Maintain the Registry public delegate voidAppliesEvent<TEvent>(TEvent @event) where TEvent : Event; public classAggregateRoot { private readonlyIDictionary<Type, Action<Event>> _handlerRegistry; protected voidRegisterHandler<TEvent>(AppliesEvent<TEvent> handler) whereTEvent : Event { var castHandler = DelegateAdjuster.CastArgument<Event, TEvent>(e => handler(e)); } protected voidApplyEvent(Event @event) { } } Will keep a list of handlers for each type of event. We’re storing the Action<Event>, but we want to call an Action<RetiredEvent>

Delegate Adjuster:From Greg Young’s Blog public class DelegateAdjuster { public static Action<TBase> CastArgument<TBase, TDerived>(Expression<Action<TDerived>> source) whereTDerived : TBase { if (typeof(TDerived) ==typeof(TBase)) { return (Action<TBase>)((Delegate)source.Compile()); } ParameterExpressionsourceParameter = Expression.Parameter(typeof(TBase),"source"); varresult = Expression.Lambda<Action<TBase>>( Expression.Invoke( source, Expression.Convert(sourceParameter, typeof(TDerived))), sourceParameter); return result.Compile(); } }

Need to Maintain the Registry public delegate voidAppliesEvent<TEvent>(TEvent @event) where TEvent : Event; public classAggregateRoot { private readonlyIDictionary<Type, Action<Event>> _handlerRegistry; protected voidRegisterHandler<TEvent>(AppliesEvent<TEvent> handler) whereTEvent : Event { var castHandler = DelegateAdjuster.CastArgument<Event, TEvent>(e => handler(e)); _handlerRegistry.Add(typeof(TEvent), castHandler); } protected voidApplyEvent(Event @event) { } } Store the handler having downcast it

Need to Apply the Event Still public classAggregateRoot { private readonlyIDictionary<Type, Action<Event>> _handlerRegistry; protected voidRegisterHandler<TEvent>(AppliesEvent<TEvent> handler) whereTEvent : Event { var castHandler = DelegateAdjuster.CastArgument<Event, TEvent>(e => handler(e)); _handlerRegistry.Add(typeof(TEvent), castHandler); } protected voidApplyEvent(Event @event) { Action<Event> handler; if (!_handlerRegistry.TryGetValue(@event.GetType(), out handler)) { throw newInvalidOperationException(); } handler(@event); } } If no handler for a mutation is registered, it’s a problem Invoke the handler

Need to Track Applied Events public delegate voidAppliesEvent<TEvent>(TEvent @event) where TEvent : Event; public classAggregateRoot { private readonlyIDictionary<Type, Action<Event>> _handlerRegistry; private readonlyICollection<Event> _events; protected voidRegisterHandler<TEvent>(AppliesEvent<TEvent> handler) whereTEvent : Event { var castHandler = DelegateAdjuster.CastArgument<Event, TEvent>(e => handler(e)); _handlerRegistry.Add(typeof(TEvent), castHandler); } protected voidApplyEvent(Event @event) { Action<Event> handler; if (!_handlerRegistry.TryGetValue(@event.GetType(), out handler)) { throw newInvalidOperationException(); } handler(@event); _events.Add(@event); } } Track the events that are being applied Make sure that the events are added.

All done now??? public classCatalogItem : AggregateRoot { privatebool _retired; privateGuid_id; publicCatalogItem() { RegisterHandler<RetiredEvent>(ApplyRetiredEvent); } public void Retire() { if (!_retired) thrownewInvalidOperationException(); ApplyEvent(new RetiredEvent(_id)); } private voidApplyRetiredEvent(RetiredEvent @event) { _retired = true; } }

Not Quite – pt. 1 Need to Expose the events for persistence & publishing Put a GetChanges() method on the AggregateRoot base class

Not Quite – pt. 2 Need to be able to rebuild the Aggregate from history Put a LoadFromHistory(IEnumerable<Event> events) method on the AggregateRoot base class Reapply the events Don’t track them as changes – overload apply event protected voidApplyEvent(Event @event, booltrackAsChange) if (add) _events.Add(@event);

Not Quite – pt. 3 Possibly memento pattern for snapshoting See Mark Nijhof’s blog & sample code on GitHub Possibly use a unit of work pattern for tracking changes

An Introduction To CQRS

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a An Introduction To CQRS

Semelhante a An Introduction To CQRS (20)

Último

Último (20)

An Introduction To CQRS

Notas do Editor