Full Spring Boot authentication microservice with Domain-Driven Design approach and CQRS.

Domain-Driven Design is like the art of writing a good code. Everything around the code e.g. database (maria, postgres, mongo), are just tools that support the code to work. Source code is the heart of the application and You should pay attention mostly to that. DDD is one of the approaches to create beautiful source code.

This is a list of the main goals of this repository:

• Showing how you can implement a Domain-Drive design
• Showing how you can implement a CQRS
• Presentation of the full implementation of an application
• This is not another proof of concept (PoC)
• The goal is to present the implementation of an application that would be ready to run in production
• Showing the application of best practices and object-oriented programming principles

GitHub repo
repo

Your contribution:

• feedback for pros&cons
• if You like the repo, star it and share

A brief overview of the architecture

The used approach is DDD which consists of 3 main layers: Domain, Application, and Infrastructure.

Domain - Domain Model in Domain-Driven Design terms implements the business logic. Domain doesn't depend on Application nor Infrastructure.

Application - the application which is responsible for request processing. It depends on Domain, but not on Infrastructure. Request processing is an implementation of CQRS read (Query) / write (Command). Lots of best practices here.

Infrastructure - has all tool implementations (eg. HTTP (HTTP is just a tool), Database integrations, SpringBoot implementation (REST API, Dependency Injection, etc.. ). Infrastructure depends on Application and Domain. Passing HTTP requests from SpringBoot rest controllers to the Application Layer is solved with “McAuthenticationModule”. In this way, all relations/dependencies between the Application Layer and Infrastructure layer are placed into only one class. And it is a good design with minimized relations between layers.

Tests
The type of tests are grouped in folders and it is also good practice and it is fully testable which means - minimised code smells. So the project has:

• integration tests
• unit test