Architecturing Architectures with NServiceBus



  • Lightweight framework for designing distributed systems in .NET
  • An Enterprise Service Bus
  • Helps to make distributed systems more:
    • Scalable
    • Reliable
    • Extensible
  • Services and support provided by Particular
  • Open Source but not free
  • Binaries available through Nuget




Request Order

Response OrderId


The website is blocked while calling the Order Service

Remote Procedure Call


Message Queue

Message: PlaceOrder


The website is NOT blocked while the place order is processed

Message oriented architecture

Windows Service

Process the PlaceOrder message




Messages in NServiceBus

  • Just simple .NET classes with properties (POCO)
  • 2 Types of messages
    • Commands
      • Do Something: PlaceOrder
      • Sent from one (or more) senders, processed by one endpoint
      • Implement ICommand
    • Event
      • Something has happened: OrderWasPlaced
      • Published from one sender, processed by several endpoints/subscribers
      • Implement IEvent


  • FIFO datastructure for storing and retrieving messages
  • Default queue in NServiceBus is MSMQ
  • Support for
    • ActiveMQ
    • RabbitMQ
    • SQL Server
    • Windows Azure Queues
    • Windows Azure ServiceBus
  • One endpoint has one queue, send-only endpoints do not have queues

Using NServiceBus to integrate systems


Command and Query Responsibility Segregation


"Command Query Separation" describes the principle that an object's methods should be either commands or queries. A query returns data and does not alter the state of the object; a command changes the state of an object but does not return any data. The benefit is that you have a better understanding what does, and what does not, change the state in your system.


CQRS is simply the creation of two objects where there was previously only one. The separation occurs based upon whether the methods are a command or a query. A command is any method that mutates state and a query is any method that returns a value.

-Greg Young, CQRS, Task Based UIs, Event Sourcing agh!


void MakeCustomerPreferred(CustomerId)
Customer GetCustomer(CustomerId)
CustomerSet GetCustomersWithName(Name)
CustomerSet GetPreferredCustomers()
void ChangeCustomerLocale(CustomerId, NewLocale)
void CreateCustomer(Customer)
void EditCustomerDetails(CustomerDetails)



void MakeCustomerPreferred(CustomerId)
void ChangeCustomerLocale(CustomerId, NewLocale)
void CreateCustomer(Customer)
void EditCustomerDetails(CustomerDetails)


Customer GetCustomer(CustomerId)
CustomerSet GetCustomersWithName(Name)
CustomerSet GetPreferredCustomers()


CQRS is a simple pattern that strictly segregates the responsibility of handling command input into an autonomous system from the responsibility of handling side-effect-free query/read access on the same system. Consequently, the decoupling allows for any number of homogeneous or heterogeneous query/read modules to be paired with a command processor.


In simple terms, you don't service queries via the same module of a service that you process commands through. In REST terminology, GET requests wire up to a different thing from what PUT, POST, and DELETE requests wire up to.
—Clemens Vasters (CQRS Advisors Mail List)

So... Simple! Right?

MS: A CQRS Journey

Event Sourcing

Still simple?

Eventual consistency

Aggregates and object-relational mapping layers

Aggregates and event sourcing

Commands and optimistic concurrency

Modelling intent

Concurrency and aggregates

idempotent messaging

Out-of-order messages

Event versioning


Communicating Between Bounded Contexts

Anti-corruption layer



By Tim Sommer