Main and Abstraction: The decoupled peers

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

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.

SpaceShip can calculcate the path to another planet

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)
SpaceShip MySQL repository is a detail

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.

Main and Abstraction relationship

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:

Layered architecture

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:

Layered architecture vs Main and Abstraction concept

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.

Hexagonal architecture

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:

Hexagonal architecture vs Main and Abstraction

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.



    • Por que crees eso? Depronto es por el significado al español de Main, que seria principal, y pues principal en software deberia ser las reglas de negocio. Pero Main se refiere al arranque del sistema, por ejemplo, en java, la clase con el metodo main, y a todo aquello que arranca con el como frameworks o bases de datos. Abstractions se refiere a las abstracciones del negocio, a las reglas de negocio, a los objetos de negocio.


      • Sí, quizás sea eso. Son términos que, a mi parecer, pueden dar lugar a confusión, pues es como si de pronto tuvieras que asumir que el símbolo de suma significa resta o algo así… no es sólo una cuestión de idioma, es una cuestión de los significados que de por sí traen habitualmente emparejados y que en este contexto ya no sirven.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s