Published on 09 January 2015 by @mathiasverraes
A message is a unit of communication between systems. There are three flavours of messages: informational, interrogatory, and imperative.
Imperative messages represent the sender’s intention. They instruct the receiver to perform an action or make a change. Do this, change that. We can model these messages as Commands. More on that in a later post.
Interrogatory messages ask the system about it’s current state, or usually a subset of that state. You know them as Queries. If you’ve done any web programming, you’ve written Queries as:
If you’ve ever talked to an SQL database, you’ve written Queries as:
If you’ve done any Object-Oriented Programming, you know that everything is an object, and so is a Query
If you’re into Domain-Driven Design, you look for the Ubiquitous Language, you dig into the domain, and you make the implicit explicit. We can make a Query message that communicates its purpose (Intention-Revealing Interfaces)
This is what is meant by Intention Revealing Interfaces in the blue book. The name
LuckyPupilsWhoDontNeedTheirParentsToSignTheirReportsAnymore is obviously exaggerated to make a point. You’ll have to admit that at least now, you’ve learned something about the domain that was tricky to infer from the previous examples.
Informational messages are sent by a system that wants to communicate something about itself to the outside world. It does this not to achieve a goal (as with imperative messages) or to learn about another system’s state (interrogatory). It provides this service for the benefit of other systems. It’s the altruistic pattern of the distributed world! (It does however have some sort of contract with it’s receivers.) It can notify an interested party directly, or through publish/subscribe (the subscribers are not hardcoded, creating better decoupling), or through broadcasting (“This is my message and I don’t care who hears it!”).
Events are one flavour of informational messages, where the sender tells others what has happened. I’ve written about Domain Events extensively. Alternatively, instead of events, the sender might simply communicate its current state. Say we have a thermometer, that emits an informational message as an event:
If the temperature changes at 08:00 and stays stable until 17:00, we have a bit of a problem. If I subscribe at 09:00, I have to wait 8 hours before I know the state. I can query the thermometer (interrogatory message), but this complicates both the sender and the receiver. The sender can resend the last event to any new subscribers, but that still means our thermometer needs to be stateful.
More realistically (disclaimer: I’ve never actually interfaced with a thermometer, so I don’t know), the thermometer is pretty dumb and simply communicates its current measurement every second:
TemperatureHasChanged is an event-flavoured informational message,
CurrentTemperature is a state-flavoured informational message. My gut feeling is that, when faced with this, I would still model state-flavoured messages as event-flavoured, by tweaking the language a little bit:
Given this categorisation, it follows from the Single Responsibility Principle that:
Follow @mathiasverraes on Twitter.
|Modelling Heuristics||Workshop @ Domain-Driven Design Europe||workshop||Amsterdam, NL||Feb 1|
|Conference||Domain-Driven Design Europe 2017||organiser||Amsterdam, NL||Jan 31 - Feb 3|
|Domain-Driven Design||Neos Conference||workshop||Hamburg, DE||Mar 30|
|Keynote (TBD)||Neos Conference||keynote||Hamburg, DE||Mar 31|
This work by Mathias Verraes is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 License.