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.

Advertisements

5 comments

Leave a Reply to Inversion of Control: Putting All Together – The Coders Tower Cancel reply

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

WordPress.com Logo

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

Google photo

You are commenting using your Google 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