Domain Oriented Messages
Greg Young has a great post titled Mocks are a code smell.
As he explains the title is to grab your attention and although he does see mocking being overused, which is definitely my view and seemed to be the general feeling at the mocking session ALT.NET UK, the post itself covers a very interesting way of handling communication within the domain.
To be honest Greg's ideas and implementations of this pattern are more advanced than mine, and I know he uses it a lot more in his designs that I do, so I'm looking forward to reading his other posts on this topic.
Trying It Out - Start Simple
If you're daunted by the idea of going to a messaging approach then you could always start simple.
As an example I would say that what Greg is suggesting is just a more advanced version of the approach that I intend to use for dirty tracking within our domain. Messages are generated when domain events happen and these will be registered with a service that you get from a service locator.
This makes testing simple as you can just use a test spy (same approach as Greg seems to be using) but is also a design that I like in terms of lowering coupling.
I think Greg made too large of a leap from "mocks are bad" to "DIP is bad". Programming against interfaces is great, but you don't have to use mocks for every interface. Stubs, fakes and dummies work just fine. Swinging the pendulum all the way back to message-based communication is quite a jump.
ReplyDeleteI can certainly see that DIP gives you other advantages but I'm really looking forward to reading more about the messaging based approach. Other people have discussed the messaging style a few times but it's always been a little vague and never really clicked with me.
ReplyDeleteOn the specifics. I agree that you wouldn't want to jump in and immediately use it all over the place but I really like the example Greg gives because we've come to a similiar design in places, but in our case the Service Locator returns a service via an interface and the service consumes the message. So we are using DIP and seperated interface but it is a messaging based approach (although a simple one).
I guess we've reached a half way solution, but half way has been good enough for us until now (though it might well not be good enough for the systems Greg works on).
Anyway I'm looking forward to reading all the debate on the topic, hopefully at the end of it I'll understand when and how to use messaging.