Specialization is strength!

Development history of a solution services oriented that thanks to the Event Sourcing allowed us to feel this architecture type’s benefits.

16 lug 2015

Development history of a solution services oriented that thanks to the Event Sourcing allowed us to feel this architecture type’s benefits.

 

OMB, our customers operating in the mechanical manufacturing industry, has expressed the need to monitor and manage the daily production with particular attention to processes that, against a fault detection, should be refurbished.

 

The developed application had to be integrate with an existing company system that care about the general production plan.

 

Analyzing the scenery, we decided that the condition was the ideal to operate a division in bounded context with an Anti-Corruption Layer (basically it is a translation layer with defensive functions, which allows us to clean our domain model to taking outside it everything that could make problems).

 

These messages are stored in queues managed by Rabbit MQ (a message-oriented middleware) and then routed to the correct user by NServiceBus (a framework of message brokering).

 

What are the benefits of an architecture like that?

 

First of all, scalability: if the application is a single block (which cannot be divided), it implies a heavier workload for the server.

 

With a service-oriented approach is possible to “divide” the application into many little applications (micro-services), each with its own independent from the others. This allows us, for example, to install single modules on different machines and then to divide the task work.

 

The second advantage is represented by the fact that during the deployment phase it’s not necessary to block entirely customer work, but it’s possible to stop only (and certainly for a time less than) the work of a specific service, the one that uses the bounded context that we’re deploying.

 

Another advantage of this “extreme specialization” is the opportunity offers us to find and fix bugs more quickly and easily.

 

And finally, thanks to this type of architecture, if the bounded context is not active when a message is generated or if the handler of a message goes wrong for some reason, the messages in not lost but simply remain in queue and after the bug are fixed, will be read and executed.

 

In short, this is a big step forward especially for the quality of customer service. You can still improve?

 

Sure! As a next step, for example, we want to divide the writing model from the reading model to better manage the complexity, like it’s theorized by the CQRS.

 

We will keep you informed!