Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

DDDD 9 [Producers and Consumers]

Not surprisingly the Producer/Consumer relationship is the single most important concept in messaging. Let’s take a look at those interfaces and how they work. The first we will look at is the interface that an object must meet in order to consume a message.

 

public interface IConsume<T>
{
void Consume(T message);
}

Next we will need something that can produce a message so we can hook up the consumer to a producer (generally used in a pipeline not for domain objects, domain objects tend to call a message publisher to act for them).

 

public interface IPublisher   
{
void Publish<T>(T message);
}

 

public interface IProduce<T>  
{
void AttachConsumer(IConsume<T> consumer);
}

 

One important fact to note is that most objects who are producers will only ever have one consumer. So AttachConsumer for most objects will throw an exception (or replace) any time that it already has a consumer and we connect another consumer to that producer (there are some notable exceptions to this rule in the framework that we will discuss later). The reason that we do this is separation of concerns. The producer does not need to know whether there is one or many consumers connected to it.

 

I think now is a great time to mention that in terms of bringing my domain to messaging these interfaces are the main leak of messaging into the domain. All of the infrastructure etc outside of my domain stays completely outside of my domain. This non-leakage of the infrastructure into our domain is a key concept as we will see shortly when we Remove Infrastructure Out Of Domain and rid ourselves of those pesky nouns inserted by our infrastructure.

 

 

One of the great parts of alt.net seattle was the chance to talk with many developers and bounce ideas off of them (ask Dave Laribee I am an “Idea Bouncer”). One of these idea bouncing sessions was with Chris Patterson and Dru Sellers who are working on (and doing a great job I should add) a light weight ESB they call MassTransit. I discussed with them my Producer/Consumer relationships that were quite different that what they were using.

 

Last night Chris came back to me with a question of whether it was explicit enough in the contract that in a request/response style message which request matched up with which response. While my “first step” in teaching someone messaging is to say “stop thinking request response” these messages can happen fairly often (though not in a synchronous fashion). What is even more likely to have happen is you have an object in a state who when it receives a message “Responds with” no a reply to the client but another routed message itself (see controller example in Mocks are a Code Smell) … In going through this conversation I started thinking back to DDD and “Intent Revealing Interfaces”.

 

What if I could create an interface that was essentially the same thing but did a better job at revealing my intent of using both of these messages in a “triggered” way.

 

    class RespondsTo<T>
{
public interface With<V> : IConsume<T>, IProduce<V>
{

}
}

 

important note: I would NOT use this interface for request/response style messaging … there are better ways of handling this… the domain object still dispatches!

 

This allows me as a user of this class to realize not only that it produces and consumes a message but that the two messages are in fact linked (when/if they are). Consider the following two examples.

 

class FooHandler : IConsume<Foo>, IProduce<Bar>

 

class FooHandler : RespondsTo<Foo>.With<Bar>

 

The second example here although it simply implements the same two interfaces gives me a lot more easily discoverable information about how that relationship interacts. A more “appropriate” example might be from the controller example

class ATMController : RespondsTo<CardInsertedMessage>.With<RequestAuthenticationMessage>

 

Take this new interface with a grain of salt as I have not spent a good deal of time playing with it yet (I prefer to re-dispatch generally and not have the producer interface on the object itself) but it would seem to be at the outset quite useful (as well as more intention revealing).

This entry was posted in DDD, DDDD, Featured. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

6 Responses to DDDD 9 [Producers and Consumers]

  1. Dave Laribee says:

    @Chris – wouldn’t request/response be better handling in a RESTful paradigm? Not sure why you’d need it on the heavy metal backend.

  2. Dave Laribee says:

    Great stuff, Greg. Keep it coming.

    Can you talk about implementing a Controller or Message Handler soon? There’s a need for content around basic asynchronous patterns (Begin/End, Polling Consumer, etc.)

    Also, can you comment (in a post) about the idea of using an Application Service as an anti-corruption layer to- and host of- the model that interfaces with our messaging context map? Here’s where I’d put a bus construct. For example:

    IService.Bus.Send
    IService.Bus.Receive
    IService.Bus.Subscribe

    Then do we host these application services or do we host our dispatcher (another post I’d like to see out of you) to send to these items. In the case of pub/sub where our domain model is sending a subscribe message it seems we’d want to have the application services hosted so they could initiate subscription. Well, if this is the case I’m a little confused how we then implement a model-per-thread (for example) pattern. Which model sends the sub?

    Does this make sense?

  3. While a lot are looking for code, it is easy to make some bad mistakes without understanding the intent behind the constructs — so I’m patient for code.

    Greg: While you continue to dismiss Request/Response, I’m curious how you would expect to handle a very common pattern in web applications. After all, the browser makes a request, and the web server sends a response. At some point, all the nifty messaging toys need to be able to wire up to that pattern for any web application to be able to use this style of design.

    We have some good examples of it in our code base (using a controller to produce and consume the request and response/exception messages) but we typically respond to the request with a response message (similar to the pattern above) and let the request handler service deal with all the other services.

    I’m sure soon enough, it will, all, be.. revealed!

  4. Greg says:

    We’re getting there Jarod … I’d say within about a week there will full code for an in-process dispatcher + an example of using it to get rid of infrastructure … After that probably some talk on more boring “messaging stuff” for a bit then the modelling of state transitions of aggregate roots as messages (which is where things get interesting and possibilities begin to open up)

  5. Jarod says:

    this stone wants to download a simple working example

  6. bjk says:

    hooligans,become fans

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>