Integration Design Principles and Domain Driven Design

If you are reading this, I assume you have some experience in Middleware technologies and can understand the basic principles behind integrations, the different architectures and design patterns.

To give some context, I have been reading a book on Domain Driven Design (DDD) by Eric Evans, to better understand the force behind the great products out there. These core principles behind a good Application architecture can be used in Consulting projects as well, especially in Middleware as we deal with multiple applications. Which is what this post is about.

The goal of a good integration is not only to connect different applications. Those are a given, and most features comes out-of-the box in middleware platforms. The best integrations are those that are scalable, reusable where possible and also resilient to changes.

Now how to achieve all of this when most of the real-world projects are run on constraints such as budget or timeline. Are there simple principles to follow to achieve a good design?

Let us go over a few key points here, while drawing in terminology from DDD with some excerpts from the book.

To create a supple, knowledge-rich design calls for a versatile, shared team language, and a lively experimentation with language that seldom happens on software projects. — Domain-Driven Design by Eric Evans

Having worked with various application teams I have learnt that each application owner or team, will have their own language they speak.
One that is their own.
The best way to connect with them, and to get the best out of business requirements is to learn and speak with them in their own language. This has helped me connect with technical team from different technologies, in a way that I can bring back into my design.
It also leads them to believe I have working knowledge of these applications, when in reality, I do not :).

What do we intend in these discussions? To better understand the application architecture and functionality, at least the parts that are relevant to the integrations in focus.

Now we cannot know everything about all the applications out there. This is where you must learn to ask the right questions, using their language.
Extract the information you need about the processes running, and how the data is generated, about the schedule, the load and all the other information
needed. Now this activity ,will go on with individual application owner, and also together where needed.

The type of integration pattern and flow of data would be more evident
after you learn to speak the language of the application teams. And remember that communication is ongoing. There will always be pieces in the puzzle
that has not come out yet. The ubiquitous language will be specific to each application when you start, and as you build upon your terminology to speak with different application teams, a better picture will emerge. And now you are ready for the next step.

If sophisticated domain experts don’t understand the model, there is something wrong with the model. — Domain-Driven Design by Eric Evans

Well, now we start modelling the integration design.

Once you are clear with the requirements, the components in the integration will be more clear. At the bare minimum you would have a consumer and a producer code pertaining to the applications in picture.
Now, what goes into the consumer and the producer? Think about whose data it is, and whose responsibility it is. When there is a change in the data from the consumer we do not want it to impact the producer code. And if producer has changes in the services they host, we do not want to be changing anything in the consumer specific code.
Those pieces of code must map to the specific component. Now what about middleware’s responsibility and is there anything that falls under middleware platforms responsibility? Well that’s where traditionally we would have a canonical model, and routing in a common component.

Here are some questions to ask yourself when modeling the integration design.

Can we design Integrations, keeping in mind that the data and structure could change? Can we keep all transformations and other middleware specific logic separate from the application specific logic for consumers and producers? Can we model the integration by dividing the components into logical units depending upon the application architecture and the specific functionality behind the integration?

In the next post, we shall look into some more concepts. Stay tuned!

Integration Architect specialized in Service-Oriented Architecture and Cloud Integrations.