A simple IoT architecture to Ingestion and Reporting — Part V

Part I | Part II | Part III | Part IV | Part VI

Context

In our fifth part, of a series of articles about IoT architects, we will cover one of the most complex services in architecture, the Rule Service. For solving the problem of this service I chose to use a different architectural approach. In this specific service, I chose to use a little of DDD (domain-driven-design) with Hexagon Architecture using a high amount of test automation (unit testing — TDD), without forgetting about SOLID principles.

Disclaimer

I chose the Spring Framework to create the architecture because my main program language is Java and I have a big experience with Spring. It’s only a preference, you can recreate all of this architecture using another program language.

Big Picture

In this article I don’t bring the usual Big Picture from the architecture, I chose to present one diagram to illustrate how the Rule Service was designed. If you would compare the Rule Service to a human body part, we can end up choosing too many different parts, we could choose: Skin, eyes, lips, or/and your tongue. What I want to say with this affirmation is: the Rule Service could be compared with our senses, because when we detect a problem or a pain, for example, these “parts of the human body” are the first ones to tell us about what is going wrong.