Software is composed by plenty frameworks, APIs, utilities and domains. With plenty of components, we usually forget what really matters in our projects.

We talked about Dependency Inversion Principle and how that helps us to create decoupling software. In this post I am going to talk about the Main and Abstraction concepts, an architectural view of Dependency Inversion Principle, and how this relates with the architectures we usually use.

Dependency Inversion Series

• Part 1: Dependency Inversion: why you should NOT avoid it
• Part 2: Main and Abstraction: The decoupled peers (You are here)
• Part 3: Inversion of Control: Putting All Together
• Part 4: Dependency Injection: Solving the Inversion of Control complexity
• Part 5: Factory Methods: Decoupling the IoC Container from the Abstraction

Let’s start with the important: The Abstraction

The Abstraction is our domain, our software logic, our entities, this is what really matter to the business, to our product owner.

This Abstraction is written in a base language (Java, Scala, .NET, Python, JavaScript, etc). The language must be sufficiently expressive to allow to create complex logic, like calculating a pay to a provider, or determinate the right path through the stars to reach Mars.

These are details: The Main

The Main is everything else that the Abstraction needs to work in a defined context, is the detail:

• Frameworks (Spring, JEE, Play, Nodejs, etc).
• Utilities (commons-xx, Lombok, Google Guava, etc).
• Databases (MongoDB, Oracle, MySql, etc).
• External dependencies to other services (SOAP, Restful, MQ, etc).
• User interfaces (AngularJS, ReactJS, JavaFX, etc).
• Infrastructure (Servers, Lambdas, Networks, etc)

Main and Abstraction relationship

Main knows a lot about Abstractions. Abstractions know nothing about Main

Main is the glue between the details and the Abstractions, it’s responsible of create, structure and compose everything in the application.

This is Dependency Inversion Principle at an architectural level.

NOTE: The Main doesn’t make sense if there is not an Abstraction to interact with.

Why this matter?

Well, we can reuse the Abstractions in different ways.

The Abstraction can be reused in multiple contexts. Each Main knows how to interact with the Abstraction, how to create it, and how to use it.

How is this related with “normal” architectures?

Well, we usually apply well establish architectures, like layered or hexagonal architectures.

Let’s check how they are a different point of view of Main and Abstraction concept.

Layered architecture

This is the most used and easy to apply. The idea is that any layer in your application is responsible of a pretty specific task. For instance:

We have a three layer architecture:

• UI: User interface, point of interaction with the final user.
• Services: Domain logic.
• Repositories: Data access logic.

Now, let’s see how Main and Abstraction looks like:

NOTE: see the red arrows, we must invert the dependency to accomplish the Dependency Inversion Principle. Abstraction lives despite of Main doesn’t, so, this is an aggregation relationship, not composition.

Hexagonal Architecture (Ports and Adapters)

This architecture is usually used when we apply Domain Driven Design.

We have the following components:

• P*: Those are ports, connections to other application/frameworks like Restful services.
• Ad*: Those are adapters, mappers/converters from domain entities to specific ports or viceversa.
• Application: This is usually the application use cases.
• Domain: Entities, specific business/problem logic.

Now, let’s see how Main and Abstraction looks like:

NOTE: Application and Domain usually have the core logic in the Hexagonal architecture, that is why we combined as a whole in the Main and Abstraction concept.

CAREFUL: Sometimes we mix the Application component with our Main, so, it is difficult to decoupling.

Final Thought

We just went further from Dependency Inversion Principle to the Main and Abstraction concept, at an architecture level.

Moreover, we saw that Main is responsible of create, structure and compose the Abstractions and everything else.

However, how does the Main do it avoiding the object creation challenge? Well, Inversion of Control (IoC) to the rescue.

If you liked this post and are interested in hearing more about my journey as a Software Engineer, you can follow me on Twitter and travel together.