The satellite model is an alternative representation of complex architectures that is propagated by me as a more helpful metaphor than layered models or complex graphs. It helps because it centres on the centre: the business or company domain. The model re-appears in many articles on my site, and in some representations by other authors:
- Alistair Cockburn Hexagonal Architecture
- Robert Martin’s plug-in architecture
- Eric Evans’ Domain Driven Architecture
- Model-Driven Architecture (OMG)
This article focusses on the simplicity and applicability of this model, which is actually a combination of some patterns:
- Adapter
- Observer
- Publish-Subscribe
Characteristics
The main characteristic is the clear and unambiguous placement of what we call the business domain: in the centre. The most important location is reserved for it. What is the business domain? It is what the system does, its objectives, its strategies. It has nothing to do with tools, technology or ICT, or in fact anything that does not directly capture the semantics of the organisation.
This is not always easy to demarcate. Is an account in a bank a business concept? Or is it a temporary technical construct because we need to track transactions? We need to decide what to include in this domain, and what not. Several rules of thumb help in making these determinations. In the article on eXploratory Modelling you can read about my favourite technique to elicit requirements from the domain experts, and about the importance of applying these two patterns:
The domain is not a model or a specification, although it might be realised from them. The idea is to create a running system. Because you have applied the rules above, this is possible. There is no dependency in the domain on persistency services or any of the other technical services. More on these components of the architecture below.
The domain component could conceptually be seen as a replica of the “real” world. I often explain it as a mirror world: it is similar but not identical to the “real” world, mainly because the two patterns are applied. It is “serviced” by technical components with the sole purpose of keeping it in sync with the “real” world. Technical components are the satellites.
Technical Components
In the satellite model the domain is not only a model, but a running component. Say we have it deployed inside a JEE session. Now in order to keep it in sync we deploy a set of technical components around it. These are the satellites.
Common components are the Persistency Service and the User Interface Service. Others might be the Security Service, the Distribution Service, and many others. There is no dependency in the satellite model between the domain component and the satellites, the technical services. The only thing flowing from the domain to the technical services are events. The domain generates these events on relevant moments in its life, in order to keep the technical services up-to-date about changes. For example an insurance policy is prolongated.
As I’ve said, there is no dependency between the domain and any other components. The technical components are updated through events propagated from the domain. However, this is not done directly. We want the technical components to be pluggable, that is, they should be built and maintained independent from the domains they are connected to.
In order for this trick to work, we need what is called adapters.
Adapters
Although adapters almost look like magicians, doing the magic that makes it all possible: to create completely independent domain components and technical services and somehow link them together, they actually are the simplest things you can imagine.
But there may be a lot of them.
Adapters can be deployed with various strategies, but they all share some characteristics. They are, as I’ve said, extremely simple. They are parameterisable, that is you can inform them about the specific domain parts and technical service interfaces they need to work with. They are created and brought to life on instantiating the solution, the whole shebang of domain components and technical services, functioning as the glue between all parties involved.
Advantages of the satellite model
As I hopefully explained successfully, the satellite model is basically very simple and easy to understand, but facilitates very complex and large architectures. An important reason for that is the enforcement of the rule that the domain components should be completely technology-independent. This helps those implementing those components tremendously because they can focus on the complexity of the business domain, almost without any burden from changes in technologies, or pollutions from technological constraints. They are free to realise these components apart from the technological hype of the day, in close cooperation with the business.
Another advantage which should not be underestimated is that now we are able to use technology in a more standardised way. The technical services should be built in a much more generic fashion, with teams that need less or in some cases no knowledge of the complex business domains.
A conceptual advantage is one I always emphasise: the domain is in the centre. That is where it belongs, if not technically. This model explicitly focusses the attention on the centre, the domain, which helps us realise why we are doing all this. By the way, in the domain components themselves I champion placing the customer in the centre. Again a reminder of why we are doing all this in the first place.
Conclusion
Although brief, I hope this exposition helps in creating some enthusiasm with the readers about applying this model in their work. If you do something similar of have any suggestions on improving the model, or applying it in specific contexts, please do not hesitate to participate in the dialog by commenting below.
