Frameworks are great. They helps us to gain productivity improve quality and unify practices. Because of our needs evolve the framework we choose today could not be the one we will need tomorrow.
Moving from a framework to another may involve a complete refactoring of the application if its architecture is not flexible enough. This is expensive, risky and often hard to justify to the business.
Application's business behaviors should not be impacted by moving from one framework to another.
The hexagonal architecture aim to isolate the more important part of our system from details. The more important part is the business logic inside the domain model. This is the heart and the rest is just a detail. The user interface is a detail. The data persistence technology is a detail.
So the goal is to make the core of the application totally framework or library agnostic.
With the hexagonal architecture each code can be placed in only one of these two areas: "IN" and "OUT".
The code inside the "IN" area belongs to the heart of your system. It contains business logic. Anything that does not contains business code is forbidden.
The "OUT" area contains everything else than business logic. The code in this area is used to query an external system, persist data or provide interfaces in order to allow external systems/users to execute our use cases. For instance these interfaces could be a web interface, a CLI, an asynchronous interface based on a message queue system, a web service.
The most important thing to understand is the dependency direction. The code in the "OUT" can depends on some code defined in the "IN" area. However it is totally forbidden that a code belonging to the "IN" area depends on code defined outside.
This is a simple rule with big impact from a quality point of view.
Examples:
- "IN" must not depends on validation annotations
- "IN" must not depends on marshaling/unmarshaling annotations
In an application we need a special kind of object who act as coordinator. They implement use cases by coordinating calls to the domain model. These object are application services.
They form a thin layer around the domain model. They are the only entry point to the domain model. From a rule point of view their are part in the "IN" area.
Application services can depends on external service in order to complete the use cases they implement. Let's imagine that for a use case send a email to a user in order to notify him that something interesting for him happened.
As previously said the application services are submitted to the same rules than the "IN" area: they must not depend on something defined in the "OUT" area.
In order to solve this problem the application layer will define a couple of interfaces describing its dependencies. The implementation of these dependencies will be in the "OUT". The dependency injection framework used by the application will do the job.
- Easier to stay focus on code that really matter.
- Communicate the intent and not the how
- Great tool to discuss about dependencies
- Great architecture tool
- The core is only composed by POJO who are easier to tests
- Application Services can use @Transactional and @Inject
- Entities can use JPA annotation in order to define persistence mapping
@Transactional Transaction demarcation
Can return entities. Accept only primitive types or DTOs.
##Packages *.application *.adapter.in *.adapter.out *.domain
###Spring Data repository interfaces
###Command & Query