The Internet of Things (IoT) is on everybody’s lips these days. I’ve been confronted with IoT architectures since more or less 10 years now, and the biggest topics are:
- Companies must react very fast. Windows of opportunity are opening and closing faster than ever. Today some IoT standard might be hot, and tomorrow it is superseeded by a bigger player.
- Devices must support different and overlapping standards.
- Testing becomes difficult when countless remote peer variants need to be compatible, and when thousands of simultaneous connections must be tested/simulated.
As a fan of SOLID, DDD and the Onion Architecture, I want to share with you, how to overcome this challenges. How to adapt new standards quickly – in the software itself and also in the test automation. And also, how to protect your core logic, your crown jewels, from an ever faster changing environment.
When using Onion Architecture one automatically regards the dependency inversion principle, and with proper application wiring, one stays automagically SOLID. It is a good idea to use DDD within the inner layers, which means (among other points) to use object instances that are named, and reflect, the Ubiqutious Language of the problem domain. The advantage of the Onion Architecture is that the Core Logic is protected (loose coupling and strong cohesion) and can easily be transferred to other environments. Furthermore all outer parts become software plugins that are easily exchangeable by e.g. unit-tests.
For an Internet of Things device, I recommend to use an abstract Protocol Translator inside the Glue Logic. This translator communicates to the outer layers by passing plain data buffers. To the core logic it communicates only by moving object instances with nice DDD Ubiqutious Language name and semantics. This way your core logic will not be polluted by the negligible details of the particular protocols, and it won’t be affected by the turmoil of IoT’s protocol wars. Such a translator can easily extended by other protocols, or just by dialects between vendors that share the same protocol.
This approach is ideal for test automation. For testing the core logic (e.g. high and concurrent traffic), the Protocol Translator can easily be replaced by a mock simulator. (Because we use the Onion model, the Protocol Translator is a replaceable plugin). And for testing the Protocol Translator itself, it can be easily surrounded by mock objects. (Again because we use the Onion model, which leads to SOLID, App-Wiring, replaceable Plugins etc.).
My Recommendation: Use a “Protocol Translator” in the middle layer of the Onion Model that speaks data buffers to the outside and DDD object instances to the core logic.