The Hexagonal Architecture is a very powerful pattern. It helps you create more sustainable and better testable software by decoupling the business logic from the technical code. The current post delves into a Hexagonal Architecture example built with Kotlin & Spring Boot named TalkAdvisor. The source code is available in this GitLab repository.
To refresh our mind, here is a schema of a high-level implementation of the Hexagonal Architecture.
Many people have understood it and this technique is now widespread. Unfortunately, we often see that the functional tests used to describe the behavior of an application, are implemented as a http client hitting the endpoints.
The main drawback of this (anti-)pattern is the mix of the testing concerns. With this type of test, we have something that has the responsibility to verify:
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.
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.
Behavior-Driven Development (BDD) is a really powerful tool that helps us build robust, value-based software. You can sometimes hear detractors say that it brings a lot of complexity and leads to long tests difficult to maintain. Let’s take stock of what BDD really is, by determining anti-patterns and best practices.
This sentence is the main symptom of a misunderstanding about Behavior-Driven Development. BDD is not a file, a test or a testing activity. It’s a development process: a methodology. You cannot write a methodology, you apply it. Most of the people believe that having written tests in a Given When…
The video of my talk @DevfestNantes 2018 (french):
voxxed Days Microservices 2018 (English version):
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.
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…
Avez-vous déjà rencontré des problèmes lors de la mise à niveau la stack de votre logiciel? Êtes-vous en mesure de distinguer vos tests fonctionnels de vos tests d’intégration ? Migrer votre legacy signifie tout réécrire de zéro? Découvrez comment l’Architecture Hexagonale, un modèle de clean architecture, également connu sous le nom de ports et adapters, peut vous aider!
Dans une expérience précédente, mon équipe a dû porter une ancienne application sur une toute nouvelle stack. Le logiciel passait d’une application EAR/SQL à un JAR autonome utilisant une base de donnée NoSQL. En l’étudiant, nous nous sommes vite rendu compte que…
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!
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…
You guessed it; the topic of this blog post is pair-programming, but not only! Instead of giving you the theoretical benefits of the pairing with some appealing assertions like “You’ll increase your productivity by x%!!!”, I’ll try to explain why in my team we decided to stop coding alone.