DEV Community: Julien Topçu

DDD/Hexagonal Architecture Tips & Tricks: Binding the Domain to the Spring Context with ComponentScan

Julien Topçu — Sun, 28 Jul 2019 00:30:42 +0000

Hexagonal Architecture tells us no framework should be present inside the domain to avoid technical accidental complexity and to ease the migration to a new structural framework (or major version) without redeveloping parts of business logics. This means that when you are using Spring, you cannot rely on any stereotype annotations such as @Service or @Component inside your domain.

Beans declaration marathon

As a result, we typically end up with bean factory methods inside Spring Configurations with a lot of boilerplate code for instantiating domain services, repositories and stubs because we think we cannot use the ComponentScan for domain objects.

This article will show you how to take advantage of the component scanning without violating the hexagonal architecture rules with code samples in Koltin. If you are working with Java, don’t worry, the code will be around the same, you’ll have to adjust a bit the syntax. Be aware that the maven part of this article is specific to Koltin, you can ignore it if you are not using this language.

The Secret: Dependency Inversion

Spring component scanning looks for annotated classes with Spring stereotypes to identify the objects you want to register in the ApplicationContext. So these objects will inevitably have a dependency on the Spring Framework, and this is basically an issue inside the domain. To get rid off this limitation, we will use the same trick used by the hexagonal architecture to ensure that your domain will never be dependent on your persistence layer: a dependency inversion.

The trick is simple, create descriptive annotations inside your domain that will identify the objects you want to expose to the ApplicationContext – usually DomainServices and Stubs.

The retention policy is set to RUNTIME to allow Spring to discover them. With the other policies, the annotation would have been discarded at run time, which is not helpful in our case. You can now safely annotate with your custom annotations the domain objects you want to expose.

You can also create descriptive annotations for the other DDD objects such as Aggregate, Entity, ValueType, Repository even if you don’t expose them to the ApplicationContext. This is a great technic to onboard people into Domain Driven Design (with some javadoc, see the example below) or simply to better understand your business and how it was modeled.

This has sometimes been useful to detect some bugs in code reviews. Like a ValueType containing an Entity, a ValueType with side effects… It is sometimes difficult to determine the nature of object we are working on, especially in rich business domains.

We will now tell Spring to treat those objects like @Service, @Component annotated ones, by configuring our custom domain annotation for scanning in the infrastructure. Simply create a DomainConfiguration and annotate as follow:

Beware that the ComponentScan looks by default only in the SpringBootApplication package, including its child packages. Thus, if your domain is not in this inverted hierarchy, you will need to specify a base package class that will identify the root package of your domain (see commented code above). Usually, we use the main domain Aggregate here since a common DDD convention encourages us to name the root domain package after him.

You can also use basePackages and give the package name as a String. But this practice is discouraged because not resilient to package refactoring.

And if you are use Java this is pretty much it, you can go directly to the Limitations section. If you are use Kotlin, you’ll be disappointed if you try to run this code. Kotlin follows the open-close principle, so every class is by default final , which means it cannot be extended. And for some reasons, maybe for bytecode injection, Spring needs bean classes to be open.

We will not use the open keyword of Kotlin to solve this issue because it would be a workaround within the domain to allow the Spring integration. Instead, we will use an out-of-the box solution using Maven.

Make SOLID lose its ‘O’

The kotlin maven plugin offers a compilation option named all-open. In this option, you can configure the classes that the kotlin compiler will open out-of-the-box and let Spring do its dirty stuff at run time. To do this, in the pom of your domain, specify the following build plugin with the full qualified name of the annotations you created above:

And now it should work with Kotlin.

Limitations

Since everything comes with a price, here are the limits of this method:

If you need some conditional or profile-based bean construction, you will have to switch back to a bean factory.
Subjective: some people dislike annotations.
If you are using Kotlin, the classes opened by the maven plugin will be now extendable, so it violates the open-close principle.

If you want to go further in the implementation of a Hexagonal Architecture based application using Maven, Koltin and SpringBoot, you can take a look at this repository.

You have critical security vulnerabilities in your software but you don’t know it yet!

Julien Topçu — Mon, 08 Oct 2018 22:36:25 +0000

Let’s start with some figures ¹²:

44% of applications contain critical vulnerabilities in open source components.

88% of Java applications have at least one vulnerability in a component.

Pretty scary! Unless you have a tracking process of the vulnerabilities in your third parties, it is very likely that you have critical security vulnerabilities in your software.

The food ain’t that bad man!

Remember this scene from the Alien movie where you can see people eating around a table and one of the guy was feeling really really bad. All the people around him didn’t undestand what was going on. And suddenly an infant form of the Alien just burst his chest! Horrible, isn’t it?

You should see hidden vulnerabilities like an Alien embryo lurking inside the chest of your application. And when it will come out, it may hurt very badly.

To avoid that, here you’ll learn:

how to know to identify those aliens and evaluates their dangerousness.
how to detect if they have infested your dependencies and also how to track them.

Know your ennemy…

All publicly know vulnerabilities are published on the internet as Common Vulnerabilities and Exposures also called CVE. This is basically a structured report normalized by the MITRE Corporation which has an unique ID e.g. CVE-2014-0160.

In those reports you can find:

The description of the vulnerability which also lists the impacted components with their vulnerable versions.
Its criticity (we will talk about that later) and impact on the infected software – how bad it can hurt you.
A list of hyperlinks giving more details on the vulnerability, it can be the analysis of the people who found it and/or an official advisory of the owner of the component which may include a fix.

The US government indexes those CVEs into the NIST National Vulnerability Database (totally public) and exposes it through the SCAP protocol. SCAP enables security tools like OWASP Dependency-Check & OWASP Dependency-Track to detect the vulnerabilities inside your third-parties.

The MITRE corporation also maintain a dictionary of software weakness types (Common Weakness Enumeration) e.g.:

CWE-326: Inadequate Encryption Strength
CWE-321: Use of Hard-coded Cryptographic Key

In each CVE reports, you will have a list of CWE weaknesses the vulnerability is exploiting. It is also used by SASTs to provide you in a standard way the weaknesses of your application. For each weakness, the CWE website provides you a description and some demonstrative examples.

Reporting of vulnerabilities is great but how could you know how important a vulnerability is ?

The Richter Scale

In order to evaluate the criticity of a vulnerability, we have a kind of “Richter Scale” named Common Vulnerability Scoring System. CVSS is an open industry standard provided by first.org.

It uses some criteria – like do we need to be authenticated to exploit the vulnerability or how confidential are the disclosed information – to compute a vulnerability score between 0 and 10. Where 0 means “that’s nothing” and 10 means “you got big troubles”.

A CVSS calculator is available on internet.

The tactical backpack

Now you know everything on “how to identify those aliens and evaluates their dangerousness”. Let’s see now how to build our first #DevSecOps Continuous-Security pipeline using OWASP Dependency-Check, OWASP Dependency-Track and Jenkins, in order to detect those aliens and track them down!

All of those tools are open-source software, so fork them on github!

https://github.com/jeremylong/DependencyCheck

https://github.com/DependencyTrack/dependency-track

Dependency-Check is a tool dedicated in the analysis of your dependencies. For each of them, it queries the National Vulnerability Database in order to verify if some CVEs have been reported. Dependency-Check currently supports Java and .NET dependencies analyzis and has experimental analyzers for Python, Ruby, PHP and Node.js applications. This tool is available in different forms: a command line, an Ant task, a Maven/Graddle plugin and a Jenkins plugin. To build our first Continuous-Security pipeline, we will focus here only on the Jenkins plugin which is really easy to use and to setup.

DependencyCheck reports can be published to SonarQube or Dependency-Track. We will also focus on Dependency-Track, a brand new tool dedicated – like you can imagine – to tracking the detected vulnerabilities inside your application.

Introducing Dependency-Track

Dependency-Track overview

Dependency-Track is a Software Composition Analysis (SCA) tool. For the short story, it brings you visibility on all the open-source components (vulnerabilities and licenses) your porfolio of application uses. We will focus here only on his vulnerabilities management system. This system integrates with multiple vulnerability databases suc as the National Vulnerability Database and the NPM Public Advisories used for the javascript-based projects. The homepage of Dependency-Track is a global Dashboard summaring the indicators and the analysis trends of the whole portfolio. What will interest us the most is the Projets page.

Here you’ll find all the analyzed applications of your portfolio. For each of them you got a sum-up of the potential vulnerabilities found. In red you have the number of the critical ones, orange for the highs and yellow for the mediums.

Let’s click on an application name to discover its related dashboard.

On this page dedicated to a single application, you got a view on all its Dependencies and also an Audit view to manage the vulnerabilities. When visiting theDependencies tab you’ll get all the libraries with their version used in your software.

For each of them, the version embedded inside your application is displayed with the number of known vulnerabilities. One cool feature here is the yellow warning symbol which appears when a newer version of the dependency is available. As you can noticed, the analyzed project in the screenshot is a maven one, Dependency-Track is querying the maven central repository to retrieve the last published version of an artefact.

The sinews of war is the Audit view.

All known vulnerabilities of the versions of your dependencies are listed here with their CVE identifier and their criticity. You have to know this is not because a known vulnerability exist on a component that you are actually vulnerable. You have to review each of them to determine if the vulnerability is exploitable in your own case.

By clicking on a vulnerability line, you are starting the review process. The description of the vulnerability is displayed and after your review you can set a status in the Analysis. You can choose between the analysis states documented here.

When you have determined a vulnerability is a false positive or doesn’t affect your software, you can suppress it by clicking the Suppress button. As a result this will no longer be taken into account in the different dashboards.

In your application, if you update a dependency to a version which is fixing a vulnerability, this vulnerability will no longer be reported by Dependency-Check and will disappear from Dependency-Track.

You can as well get more information on the vulnerability if you click on its CVE identifier.

That’s mainly the information of the CVE report. The CVSS score is displayed as the Base Score on the right.

Dependency-Track also offers an aggregated view of all the dependencies used of the whole portfolio inside the Components tab.

The main feature of this view is the ability to review a vulnerability for the entire portfolio. This is really helpful when you want to suppress false positive/not affected vulnerabilities which are reported on several applications. For that, click on the name of the dependency, go to the Vulnerabilites tab and activate the Audit Mode

But be careful of what you are doing to avoid any scaled false negative! Note that you cannot choose the projects on which the analysis status will be set, the status will be set globally for the entire portfolio. The Projectstab will show you all the projects on which this vulnerability has been found.

Dependency-Track is updating regularly its mirror of the NVD database. As a result it will automatically update the vulnerabilities report of a software if a new vulnerability has been reported. Obviously, if a new dependency or a dependency version has changed in your code base, Dependency-Track will not know about it. A new Dependency-Check analysis will be required to notify Dependency-Track.

Need some ChatOps capabilities ? Dependency-Track can notify your favorite chat tool!

Review Tips & Tricks

False Positive ? You might have seen that you can set a vulnerability as false positive, but how can it be possible? Well sometimes the CVE report is not enough precise regarding the impacted components. As a result a vulnerability regarding a database server can be reported on your software because you are using the related database driver.

Struggling with the vulnerabilities. You’ll see that sometimes this is really hard to figure out if a vulnerability is actually exploitable on your software. Instead of investing a lot in the investigation, you can simply update your dependency to the version where the vulnerability is fixed. In fact, it should be the default behavior to adopt if the new version doesn’t require to rewrite large parts of your application. The older a dependency is, higher is the risk.

*A vulnerability has been found, but you got the very last version of the impacted component. * The first thing to do, is to look for the criticity and the exploitability of the vulnerability, this is basically given by Dependency-Track on the CVE dedicated page.

You might risk waiting for the new version of the component if the vulnerability has a low score, low impact and is difficult to exploit. But if this is critical, you may be able to find a workaround in the links of the CVE report.

You should also reconsider the use of frameworks that are no longer maintained or are not responsive enough to correct known vulnerabilities.

Do your first step into the #DevSecOps!

Install this plugin in your Jenkins instance. If you don’t have any Jenkins yet, you can easily set up one using docker.

By default, Dependency-Check will download a local copy of the NVD database for every Jenkins job. This process can be long (>10 minutes) so it is recommended to configure a dedicated job to download and update a shared database. You can skip the shared database setup for testing purpose.

In Manage Jenkins > Configure System > Dependency-Check > Global Data Directory , Set the path of a shared directory by all your jobs to store the database.

Setup a dedicated NVD database update job using a free-form jenkins job , and configure it like this:

The build trigger will ensures the job will be launched nightly only once a day. It is not required to update the local NVD database more frequently. Now add a new build step Invoke Dependency-Check update only.

This build step will only update the local NVD database. You don’t need to specify the _Data directory _containing the database dump since you have previously set it globally.

Run it manually to initiate the database.

Thanks to this you have a local NVD database instance which is shared among all your jobs.

Now you can create your first analysis job! Here you just need a job which gather all the dependencies of your application, you can directly download them using the maven-dependency-plugin using mvn dependency:copy-dependencies or by unpacking your Spring Boot jar.

Even better: you don’t have to specify anything if you are using a NPM or a Maven based application. The plugin will automatically detects and scan the package.jsonor the pom.xml file.

Assuming all yours dependencies are gathered inside target/deps/lib/ , simply add the following *post-build step * to specify the path to be scanned by Dependency-Check.

Note: If you are building a SpringBoot application, you can unpack your jar and your dependencies will be bundled inside the BOOT-INF/lib/ (spring-boot-maven-plugin ≥ 1.4) or directly *lib/ * (spring-boot-maven-plugin < 1.4).

As an alternative, you can use the dependency-check-maven-plugin which requires a bit more configurations. Additional Dependency-Check integrations are available here.

At the end of the analysis, dependency-check-report.xml will be generated. You can ask the Dependency-Check plugin to publish it inside the jenkins job by adding this following Post-build Action :

As a result, you’ll get a new menu *Dependency-Check Vulnerabilities * inside your job. You will be able to see here which dependencies have known vulnerabilities.

We won’t dig much about it here, since the Jenkins view is a lite version of what Dependency-Track offers. In Jenkins you can only explore the content of the report. With Dependency-Track, you’ll be able to triage those vulnerabilities.

Dependency-Track provides a docker image:

Dependency-Track container requires 4GB of memory , make sure to configure docker accordingly (2GB by default).

docker pull owasp/dependency-track
docker volume create --name dependency-track 
docker run -d -p 8080:8080 --name dependency-track -v dependency-track:/data owasp/dependency-track

This docker image allows Dependency-Track to be ran in a standalone mode using an embedded h2 database. This is pretty handy for testing purpose but you should not use it for a real continuous-security pipeline. Dependency-Track offers several database integrations for production mode.

Dependency-Track also requires a local copy of the NVD database. So during the first run, the initial download of the database may take a while.

You can now integrate Dependency-Track with Jenkins by installing this OWASP Dependency-Track Plugin.

Connect to Dependency-Track using http://your-container-ip:8080 and login with admin:admin.

To create a new project in Dependency-Track, click on the second icon on the left and then on the button + Create Project.

A Create Projectpopup should appear. As project name, enter the name of the software you want to analyze; the other fields are optional.

The Jenkins plugin requires an API Key, to generate one, go to the Administration > Access Management > Teams page (the gears icon on the left). In this page you’ll be able to manage the users of Dependency-Track with their permissions. You can also setup Teams of users with specific permissions, by default an Automation team is provided for the external tools that needs to interact with Dependency-Track.

Click on the Automation team, and copy the existing API Key (or generate a new one).

You will be able to generate API Keys for every teams but not all of them share the same permissions. For example, by default, the Automation team provides enough rights to upload a scan to Dependency-Track (SCAN_UPLOAD), which is not the case of the Portfolio Managers team. As a result, an api key of this last team won’t enable an scan upload.

Go back to Jenkins and navigate to Manage Jenkins > Configure System > Dependency-Track , fill there the URL of Dependency-Track and the API Key.

Tips: If you are running both Dependency-Track and Jenkins inside docker containers, make sure they are connected to the same docker network.

To create a network between two docker containers, create first your network:
docker network create <network-name>
Then connect your containers to it
docker network connect <network-name> <container-name>

Now update your Dependency-Check job to add a post-build action in order to publish the vulnerability report to Dependency-Track.

In Dependency-Track project , select the name of the project you just created.

Inside Artifact put the path of the Dependency-Check report, usually dependency-check-report.xml and make sure the Artifact Type is set to Dependency-Check Scan Result (XML).

Run your analysis job and go back to the projects view of Dependency-Track. You should now see the result of the report in the Vulnerabilities column.

Dependency-Track also offers a NVD mirroring feature, which helps to optimize the Dependency-Check database download process.

*Congratulation!!! You just set-up your first Continuous-Security pipeline, #devSecOps FTW! * And now you can be compliant with one of the best practices of the OWASP TOP10³ A9-Using Components with Known Vulnerabilities.

Special thanks to Axel Ayigbede from highergroundz who has made the illustrations!

Hexagonal Architecture: the practical guide for a clean architecture

Julien Topçu — Sat, 19 Aug 2017 18:00:22 +0000

Did you ever face problems when comes the time to upgrade the stack of your software? Are you able to distinguish your functional tests from your integration ones? Migrating your legacy means rewriting everything from scratch?

Discover how the Hexagonal Architecture, a clean architecture pattern also known as Ports and Adapters, can help!

Business logic overboard!
Separation of concerns: isolating the business logic
No frameworks allowed in the domain
The Hexagonal Architecture Inversion of Control
Protecting the domain with an anti-corruption layer

The modularity strength of the Hexagonal Architecture
How to implement the Hexagonal Architecture?
A Test-Driven implementation
Hexagonal Architecture in a nutshell

Business logic overboard!

In a previous experience, my team had to port an old application on a brand-new stack. The software was moving from an EAR/SQL app to a self-contained JAR using NoSQL. By studying it, we quickly realized that we had to redo the entire infrastructure. In fact, the only thing that didn’t have to change was the business logic. So, it makes sense to reuse it, right?

a classic layered architecture implementation

After a deeper look, the maven module named model was POJOs with only getters and setters, totally anemic… Although there is also service module, the business logic is shared across all the layers. It was drowned in a lot of technical code such as DAOs creation, Serialization, etc. There were no ways to extract the business logic! Some parts of it were relying on the technical behavior of the old framework we tried to remove. And why? Because there was no clean separation between the business logic and the technical code.

Separation of concerns: isolating the business logic

The Hexagonal Architecture created by Alistair Cockburn ensures the re-usability of the business logic by making it technical-agnostic. So, changing the stack will have no impact on the domain code.

One key concept of this architecture is to put all the business logic into a single place named the Domain. Let’s update the previous schema:

overview of a layered architecture

Important constraint: the domain depends on nothing but itself ; this is the only way to ensure that the business logic is decoupled from the technical layers. How do we achieve that on the previous schema? The domain clearly depends on the persistence layer! Well, by using a pattern you may know: the inversion of control. By calling the domain the Hexagon, it will look like this:

Overview of a Hexagonal Architecture

The inversion of control was pretty magic, let’s see later how it works. Now you got an overview of what is the Hexagonal Architecture:

Only two worlds, inside and outside the Hexagon. Inside: all the business logic , Outside: the infrastructure – meaning all your technical code.
The dependencies always go from outside toward the inside of the Hexagon. It ensures the isolation of the business domain from the technical part.
One corollary of this is the Hexagon depends on nothing but itself. And not only regarding your own layers: It must not depend on any technical framework. That includes external annotations like Jackson or JPA.

No frameworks allowed in the domain (almost)

Let me explain you a bit more the last point, which is a really important one. In another experience, my team had to port an application from the “classic” Spring framework to Spring Boot. The main (painful) problem we had: leveraging too much on the Spring Integration Tests to validate our functionalities. Furthermore, those functionalities were also too coupled with Spring.

At the first try of our Spring Boot migration, all functional tests were failing. We were not able to determine if the business logic was broken somewhere or if the reason was purely technical. We eventually figured out that it was an integration problem at test level. So we fixed all the tests one by one by crossing our fingers… Hoping the domain was still correct.

No framework used in the Hexagon means the business domain can be reused regardless the change of the technical stack. It will as well increase the testability of your domain since you no longer mix it with integration issues. And at the end, you’ll do real functional tests thanks to this constraint of the Hexagonal Architecture. This way the functional tests will directly interact with the Hexagon and only with it.

NOTE: In Maven, you can ensure this constraint using the enforcer plugin.

The Hexagonal Architecture Inversion of Control

Remember the inversion of control? To ensure the isolation of the Hexagon, the dependencies on downstream layers have been inverted. The trick is in fact pretty simple as you can see:

Implementation of the Hexagonal Architecture

The outside of the Hexagon (the infrastructure) is divided in two virtual parts, the left side and the right side. On the left, you got everything that will query the domain (the controller, the REST layer, etc.). And on the right, everything that will provide some information/services to the domain (persistence layer, third party services, etc.).

Protecting the domain with an anti-corruption layer

To let the outside to interact with the domain, the Hexagon provides business interfaces divided in two categories:

The API gathers all the interfaces for everything that needs to query the domain. Those interfaces are implemented by the Hexagon.
The SPI (Service Provider Interface) gathers all the interfaces required by the domain to retrieve information from third parties. Those interfaces are defined in the Hexagon and implemented by the right side of the infrastructure. We will see that on some circumstances, the Hexagon can also implement the SPI.

There are two important facts here:

The API and the SPI are parts of the Hexagon.
The API and the SPI only manipulate domain objects of the Hexagon. It indeed ensures the isolation.

In a layered architecture, the Business Object or the service usually creates the DAOs. In the Hexagonal Architecture, the domain only handles domain objects. Consequently, the persistence is in charge to translate the domain objects into any “DAOs” to be persisted. This is what we call an adaptation.

The modularity strength of the Hexagonal Architecture

As mentioned above, the Ports and Adapters architecture is another name of the Hexagonal Architecture. It comes from the power of the modularity of this architecture. Because everything is decoupled, you can have a REST and JMS layers in front of your domain at the same time without having any impacts on it.

Adapters modularity in Hexagonal Architecture

On the SPI side, you can change from a MongoDB driver implementation to Cassandra if needed. Since the SPI won’t change because you change the persistence module, the rest of your software won’t be impacted. The API and the SPI are the Ports and the infrastructure modules using or implementing them are the adapters.

How to implement the Hexagonal Architecture?

One more rule here: always start with the inside of the Hexagon. This will bring you a lot of advantages:

Focus on the feature instead of the technical details. Because only the feature brings value to your company. A developer working on another business domain is able to put in place a Spring Controller. But the double declining balance method will sound like Wookiee for him unless he worked for an accountancy company.
Delay choices on technical implementation. Sometimes it’s really hard to know which technical implementation you really need at the beginning. Consequently, delaying this choice helps you to focus on what brings the primary values to your company – the feature. Furthermore, after the implementation of the business logic, some new elements can help you to make the best choice regarding your infrastructure. You can discover that the domain is more relational than expected, so SQL is a good choice for your database.
One corollary is it ensures the Hexagon is a stand-alone. Since you should never write code without tests, it means that the Hexagon is self-tested. Furthermore, we got here real functional tests focusing on the business only.

A Test-Driven implementation

With the Hexagonal Architecture, you put your functional tests in your domain. Those tests will call directly the domain API while avoiding any disturbance from the technical part. In a way you are creating an adapter simulating the Controller to test the features of the domain.

Starting with the functional tests of the Domain

My advice is writing your functional scenario first using the Behavior-Driven Development to describe your feature.

The first step of the “double-loop” will produce your functional test using ATDD. And write the API interface which will be the entry point of your feature. Then implement your tests with TDD and finally implement your business logic. While writing it, you might need to retrieve some data from the database for example, so create an SPI. Since the right side is not yet implemented, create a stubbed implementation of this SPI inside your Hexagon. That can be achieved using an in-memory database implemented with a Map.

Functional Tests in Hexagonal Architecture

You can choose to keep the Stubs in the test scope of your application. But you can as well temporarily ship it if needed. For example, once we made the first feature on the Hexagon, we stubbed an external service and the database. Because our client needed us to provide an interface contract, we secondly exported the domain through a REST controller. So we shipped a first version with stubbed data on the right side of the infrastructure. This way, the client was able to see the structure of our data and the expected behavior of the feature. It was much more reliable than creating by hand some JSON samples of our requests and responses because it actually deals with real business constraints.

Finishing with the adapters

The next step is usually opening the left side first. This way you can put in place some integration tests on the feature. At this time you can provide some live documentation and ensure an interface contract with your clients.

Hexagonal Architecture integration test of a left adapter

Finally, open on the right by implementing the SPI of your feature by taking advantage of the integration tests. I strongly recommend your tests to be stand-alone to avoid any instability during build time. You should always mock your third parties using something like Wiremock for external services or Fongo to simulate a MongoDB.

Hexagonal Architecture end-to-end integration test

Loop the same way for your other features.

Architecture Hexagonale Level 2 : Comment bien écrire ses tests ? by Julien Topçu & Jordan Nourry

For more information, an Hexagonal Architecture Testing Strategy is available on GitLab which is also described in the talk above 🇫🇷!

Hexagonal Architecture in a nutshell

So, now we have seen what is Hexagonal Architecture! There is a real benefit in decoupling the business logic from the technical code. It ensures your business domain is durable and robust regarding the continuous evolution of the technology.

The Hexagonal Architecture offers you a real means to achieve this by:

Putting all the business logic in a single place.
The domain is isolated and agnostic regarding the technical part because it depends on nothing but itself. That’s why the dependencies always go from outside to the inside of the Hexagon.
The Hexagon is a stand-alone module. Thus, It increases the testability of your domain by writing real functional tests which don’t have to deal with technical issues.
This architecture offers a powerful modularity. It helps you to write as many adapters as needed with a low impact on the rest of the software. And since the domain is agnostic from the stack , the stack can be changed without any impact on the business.
By always starting with the domain , you ensure to bring value to your customer by focusing on the feature development. This way you can delay choices on technical implementation to make the best choice at the right time.

Some feedbacks

Hexagonal Architecture is not suitable for all situations. Like Domain-Driven Design, this is really applicable if you got a real business domain. For an application which transform a data to another format, that’s might be overkill.

To finish on this, always be pragmatic when you adopt a new technology. As stated before, the Hexagon must not depend on any technical framework, but exceptionally you can. For example, in our case the Hexagon had three exceptions: Apache Commons Lang3 (StringUtils), SLF4J and the JSR305 of Findbugs. Because we didn’t want to create the wheel since those frameworks had very low impacts on the domain. One good side effect of the Hexagonal Architecture, is that you keep challenging yourself before integrating a new framework. By using this architecture, we reduced the number of dependencies from fifty to only three or four for the domain. And this is very good from a security perspective.

Further readings
Want to go further? Checkout those Domain-Driven Design and Hexagonal Architecture tips&tricks series

You can also find here a great article on the Hexagonal Architecture: https://softwarecampament.wordpress.com/portsadapters/

And if you to see some code, you can now find on GitLab a Kotlin/Spring Boot Hexagonal Application.

French version: Architecture Hexagonale : le guide pratique pour une clean architecture.

The post Hexagonal Architecture: the practical guide for a clean architecture appeared first on BeyondxScratch.