Activities

	*ALT.NET Events* What's Going On?
	*Statistics* Statistics
	*Test the Wiki* Play in the Sandbox
	*Get help* Help Pages
	*Discuss* ScrewTurn Forum
	*Learn more* ScrewTurn Blog
This wiki is licensed under a Creative Commons Licence.
Back History
Distributed Domain Driven Design

	There are well established ways to create rich domain models to build systems on, but there is not much on how to use this in a distributed or event driven systems.  One of the key tenents of DDD is to decouple the infrastructure and the domain.  

So how do you handle messaging?  Is it part of the infrastructure, or is it separate from the infrastructure?  One way to handle this is to using a Saga.

So for example you create a user on a website.  Your page calls a service which creates a new user domain object, persists it in an incomplete state.  An email goes out to asking the user to confirm their account.  When they do, your page calls another service, which loads the customer and then marks it complete.

In an event driven system, you base everything on an event, which might be fired by a customer, an employee or some other system.

	There are several kinds of messaging, some are external, and others are internal to the domain.  The question is what kind of messaging is appropriate when? 

	You could use messages to allow for great scalability and fault tolerance, but this is overkill for most applications. 

	Again there are different kinds of messages; in some architectures (such as a hub and spoke) sagas may not be as important, because your broker will handle this stuff.  In a more distributed scenario, sagas are very important.

	The notion of messages inside the domain is a pretty new idea.  One reason to do this is to further decouple the infrastructure from the domain.  Instead of an email gateway, you have a send email message.  On the other hand you could also view this as separating orthogonal concerns, not really messaging.

	Services that are nouns in the ubiquitous language, is a bad sign, you should be able to talk about the action (a verb) instead of the service.

	Using messaging with domain driven design is very difficult, because each subject is complicated already.

	You have to consider the endpoints of your messages so you can understand the throughput of a system.  This leads to questions about what does scalability of a system cost.  There are also a lot of other concerns you have to look at, including availability and reliability.

	Availability is also a cost function, more availability costs more money, so how much money your business makes must be considered.

	Taking a step back, you want to optimize your ubiquitous language, but you must still look at the architecture.  A saga might replace several services, in some cases; a saga will encapsulate the services rather than replace it.

	Some resources that are useful for this subject matter are Martin Fowler’s book Patterns of Integration Architecture.

	One concern is when you are trying to move a system from a synchronous model to a messaging / asynchronous model.  When you are looking at a system built with messages, the parts are fairly simple.  With a one way messaging architecture, you can handle many scenarios, from occasionally connected to always connected.  

What practices are appropriate when moving to a message based solution?  Caching is handled differently when you are using messaging.  You have to look at failure conditions, whereas when you are using a request/response model, you can ignore it.

	Another question is how much design do you have to do up front?  You have to make some general decisions before you can get started.  If you are building a multithreaded server, you will have to kill some threads.  The way to handle this is to throw and exception in the domain model, but not bubble it all the way back to the client.

	Instead, you want to let the message get pushed back into the queue, and let it be sent again.  On the other hand, you have to handle a poison message.  You might want to put in a different queue, so it can be processed later.

	A related scenario is when you don’t send a response right away.  In this case, you have to look at the temporal aspect.

	Stepping back, why do you head in the direction of building a message based system?  Anything that changes state in the domain model will be captured in an object (such as a command object).  You still store and persist the command object, so you have a record of what happened.  Now you have a complete audit of all changes, and it is much easier to synchronize with a central database.

	You also don’t have to persist every state change.  This allows you to have conflict management when you have an occasionally connected system.  You also want to avoid chatty messages, which might contain several smaller objects.

	Each small object that you put in a larger message is part of a contact, so you can avoid duplicating messages.  It does not matter if you keep each event as its own message, the endpoint should be able to handle the events together or separate.

	When you are looking at two components interact, there are a couple of styles of interaction.  One is request / response, the other is publish / subscribe.  Of course, you will have to keep all the data on the end of each subscriber.  Request / response must be coarse grained, whereas publish / subscribe can have a finer grained contract.

	On of the most important questions is how do you get into these kind of messaging systems.  Read the existing knowledge, and break away from the request / response model.
altnetpedia

Navigation

Activities

Distributed Domain Driven Design
