Hexagonal Architecture — Implementation in Java

In this tutorial, we’ll walk through a simple implementation of the hexagonal architecture. Alistair Cockburn proposed this concept in 2005.

This architecture is also called “Ports and Adapters” and “Object Structural”.

We’ll go through the concepts first and then learn the implementation of this architecture using Java.

Concept

Hexagonal Architecture defines that an application’s business logic should be isolated from the external applications.

Based on this concept, we can divide our application into 3 parts. The business logic will be the inside of an application. The user and server sides of the application would be the outside of an application.

#java #rest-api #design-patterns #hexagonal-architecture #programming #hexagonal architecture — implementation in java

What is GEEK

Buddha Community

Hexagonal Architecture — Implementation in Java
Tyrique  Littel

Tyrique Littel

1600135200

How to Install OpenJDK 11 on CentOS 8

What is OpenJDK?

OpenJDk or Open Java Development Kit is a free, open-source framework of the Java Platform, Standard Edition (or Java SE). It contains the virtual machine, the Java Class Library, and the Java compiler. The difference between the Oracle OpenJDK and Oracle JDK is that OpenJDK is a source code reference point for the open-source model. Simultaneously, the Oracle JDK is a continuation or advanced model of the OpenJDK, which is not open source and requires a license to use.

In this article, we will be installing OpenJDK on Centos 8.

#tutorials #alternatives #centos #centos 8 #configuration #dnf #frameworks #java #java development kit #java ee #java environment variables #java framework #java jdk #java jre #java platform #java sdk #java se #jdk #jre #open java development kit #open source #openjdk #openjdk 11 #openjdk 8 #openjdk runtime environment

Hexagonal Architecture — Implementation in Java

In this tutorial, we’ll walk through a simple implementation of the hexagonal architecture. Alistair Cockburn proposed this concept in 2005.

This architecture is also called “Ports and Adapters” and “Object Structural”.

We’ll go through the concepts first and then learn the implementation of this architecture using Java.

Concept

Hexagonal Architecture defines that an application’s business logic should be isolated from the external applications.

Based on this concept, we can divide our application into 3 parts. The business logic will be the inside of an application. The user and server sides of the application would be the outside of an application.

#java #rest-api #design-patterns #hexagonal-architecture #programming #hexagonal architecture — implementation in java

Samanta  Moore

Samanta Moore

1620458875

Going Beyond Java 8: Local Variable Type Inference (var) - DZone Java

According to some surveys, such as JetBrains’s great survey, Java 8 is currently the most used version of Java, despite being a 2014 release.

What you are reading is one in a series of articles titled ‘Going beyond Java 8,’ inspired by the contents of my book, Java for Aliens. These articles will guide you step-by-step through the most important features introduced to the language, starting from version 9. The aim is to make you aware of how important it is to move forward from Java 8, explaining the enormous advantages that the latest versions of the language offer.

In this article, we will talk about the most important new feature introduced with Java 10. Officially called local variable type inference, this feature is better known as the **introduction of the word **var. Despite the complicated name, it is actually quite a simple feature to use. However, some observations need to be made before we can see the impact that the introduction of the word var has on other pre-existing characteristics.

#java #java 11 #java 10 #java 12 #var #java 14 #java 13 #java 15 #verbosity

Fannie  Zemlak

Fannie Zemlak

1595927640

Road to Simplicity: Hexagonal Architecture [Part One]

Software writing taught me that: a well written software is a simple software.

So I started to think how to achieve simplicity in a methodological

way. This is the first story of a series about this methodology.

Naturally it’s a snapshot because it’s in constant evolution.

Simplicity

A definition of simplicity is:

The quality or condition of being easy to understand or do.

Oxford dictionary (https://www.lexico.com/en/definition/simplicity)

So, a simple software is a software that is easy to understand.

After all software are written by humans for humans. This implies

that they should be understandable. Simplicity guarantees that its

understandability isn’t an intellectual pain.

A software solves a problem. So to build the former you should understand the latter.

But to build a simple software you should understand - clearly - a problem.

First step: architecture

On the Martin Fowler blog there is a deep definition of architecture and its explanation:

“Architecture is about the important stuff. Whatever that is.”

On first blush, that sounds trite, but I find it carries a lot of richness.

It means that the heart of thinking architecturally about software is to decide what is important, (i.e. what is architectural), and then expend energy on keeping those architectural elements in good condition.

Ultimately the important stuffs are about the solved problem. In other words about the software domain.

So we need an architecture that allows us to express - clearly - the software domain.

I think that the hexagonal architecture (a.k.a. ports and adapter architecture) is an ideal candidate.

It’s based on layered architecture, so the outer layer depends on the inner layer. Each layer is represented as a hexagon.

Here a UML-like diagram to express the below concepts:

In this architecture the innermost hexagon is dedicated to the

software domain. Here we define domain objects and we express clearly:

  • what the domain does as input port or use case (I prefer the latter because expressiveness).
  • what the domain need, to fulfill use cases, as output port.

Conceptually on the sides of the domain layer there are use case and output port interfaces.

The communication between the outer layers and the domain layer happens through these interfaces.

The outer layer provides output port implementations and they use the use case interfaces.

The implementations and use case clients are are called adapter. Because they adapt our interface to a specific technology.

This relation is an instance of the dependency inversion principle. Simply put: high level concept, the domain, doesn’t rely on a specific

technology. Instead low level concept depends upon high level concept.

In other words our code is technology agnostic.

As you can see the concepts expressed in the outer layers are just details.

The real important stuff, the domain, is isolated and expressed clearly.

Code

A little project accompanies this series to show this methodology. It’s written in Java with the reactive paradigm from the beginning. For this reason the ReactiveX library is also used in the domain layer.

The software analyzes the capabilities (e.g. the java version, the

network speed and so on) of the machine and it exposes them through REST API.

It’s inspired by a real world software that I wrote because of work.

The first step is to define the innermost hexagon.

We can already identify:

  • the main use case, expressed as GetCapabilitiesUseCase
  • the object that describe the machine capabilities, expressed as Capabilities

The use case is an interface:

(if you never used ReactiveX: a Single means that the method will return asynchronously an object or an error)

public interface GetCapabilitiesUseCase {
  Single<Capabilities> getCapabilities();
}

The Capabilities objects are immutable (precisely they’re value objects). And there is an associated builder (I’m using lombok annotations to generate the code):

@RequiredArgsConstructor
@Value
@Builder
public class Capabilities {
  private final String javaVersion;
  private final Long networkSpeed;
}

#architecture #software-architecture #programming #java #hexagonal-architecture #reactive-programming #software-development #software-engineering

Samanta  Moore

Samanta Moore

1620462686

Spring Boot and Java 16 Records

In this article, we will discuss Java 16’s newest feature, Records. Then we will apply this knowledge and use it in conjunction with a Spring Boot application.

On March 16th, 2021, Java 16 was GA. With this new release, tons of new exciting features have been added. Check out the release notes to know more about these changes in detail. This article’s focus will be on Java Records, which got delivered with JEP 395. Records were first introduced in JDK 14 as a preview feature proposed by JEP 359, and with JDK 15, they remained in preview with JEP 384. However, with JDK 16, Records are no longer in preview.

I have picked Records because they are definitely the most favored feature added in Java 16, according to this Twitter poll by Java Champion Mala Gupta.

I also conducted a similar survey, but it was focused on features from Java 8 onwards. The results were not unexpected, as Java 8 is still widely used. Very unfortunate, though, as tons of new features and improvements are added to newer Java versions. But in terms of features, Java 8 was definitely a game-changer from a developer perspective.

So let’s discuss what the fuss is about Java Records.

#java #springboot #java programming #records #java tutorials #java programmer #java records #java 16