ivanpaulovich / hexagonal-architecture-acerola

An Hexagonal Architecture service template with DDD, CQRS, TDD and SOLID using .NET Core 2.0. All small features are testable and could be mocked. Adapters could be mocked or exchanged.

Acerola: Hexagonal Architecture

Acerola is a Service Template for helping you to build evolvable, adaptable and maintainable applications with Hexagonal Architecture. It follows the principles from the Alistair Cockburn blog post. and has a Domain built on Domain-Driven Design. It is easy for you to start your new microservice based on its guidelines and patterns.

Compiling from source

To run Acerola from source, clone this repository to your machine, compile and test it:

git clone https://github.com/ivanpaulovich/acerola.git
cd acerola/source/WebAPI/Acerola.UI
dotnet run

The Architecture

Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases.

As events arrive from the outside world at a port, a technology-specific adapter converts it into a usable procedure call and passes it to the application. The application is blissfully ignorant of the nature of the input device. When the application has something to send out, it sends it out through a port to an adapter, which creates the appropriate signals needed by the receiving technology (human or automated). The application has a semantically sound interaction with the adapters on all sides of it, without actually knowing the nature of the things on the other side of the adapters.

Concept	Description
DDD	The Use Cases of the Account Balance are the Ubiquitious Language designed in the Domain and Application layers, we use the Eric Evans terms like Entities, Value Object, Aggregates Root and Bounded Context.
TDD	From the beginning of the project we developed Unit Tests that helped us to enforce the business rules and to create an application that prevents bugs intead of finding them. We also have more sophisticated tests like Use Case Tests, Mapping Tests and Integration Tests.
SOLID	The SOLID principles are all over the the solution. The knowledge of SOLID is not a prerequisite but it is highly recommended.
Entity-Boundary-Interactor (EBI)	The goal of EBI architecture is to produce a software implementation agnostic to technology, framework, or database. The result is focus on use cases and input/output.
Microservice	We designed the software around the Business Domain, having Continous Delivery and Independent Deployment.
Logging	Logging is a detail. We plugged Serilog and configured it to redirect every log message to the file system.
Docker	Docker is a detail. It was implemented to help us make a faster and reliable deployment.
MongoDB	MongoDB is a detail. You could create new Data Access implementation and setup it with Autofac.
.NET Core 2.0	.NET Core is a detail. Almost everything in this code base could be ported to other versions.
CQRS	CQRS is an acronym for Command Query Responsibility Segregation. This pattern allow splitting our conceptual business model into two representations. The main representation resides on the Command Stack, to perform creates, updates and deletions. The display model resides inside the Query stack, where we can build a Query Model that make easier to aggregate information to display to clients and UI.

Flow of Control: The Register Use Case

Requirements

• Visual Studio 2017 with Update 3
• .NET SDK 2.0
• Docker

Prerequisites Setup

The only one prerequisite to run the Web API is a valid connection string to MongoDB. To help you run it without hard work follow the steps on prerequisites setup page.

Running the latest Docker Build

You can run the Docker container of this project with the following command:

$ docker run -d -p 8000:80 \
	-e modules__2__properties__ConnectionString=mongodb://10.0.75.1:27017 \
	--name acerola \
	ivanpaulovich/acerola:latest

Then navigate to http://localhost:8000/swagger and play with de Swagger.

Live Demo on Azure

You can play with the latest build of Acerola.

This source code and website should be used only for learning purposes and all data will be erased weekly.

hexagonal-architecture-acerola's Issues

Role Based Apis

If the same resource can be accessed by different roles and perhaps differently, where to place that logic. For example, a manager can make any customer account inactive but a customer can only make his/her account inactive. What is better to have a separate for both roles, or a single api /account?customerId=1 and have a if/else inside the controller or domain rule. There can be multiple roles in the real case. What do you prefer?

Repository interface in the application layer

Hello,
I am wondering why do you added repository interfaces in the application layer? Many examples show the interfaces in the domain layer.

Question about structure of your project

Hi,

I'm new in architecture hexagonal approach.
And I have some question/remarks about your project.

• What is "application" folder ?
• I expected to have port in "domain"
• there is no "domain service" in "domain"
  In architecture hexagonal I think service from "application" should be in domain.

I like useCase class approach. This is an approach from DDD ?

Thanks for your project.

MediatR

Olá, parabéns pelo projeto.

Por que da remoção do MediatR?

Where is domain logic in your domain?

I can't find any domain logic or scenarios in Domain. No any driven or driving adapters in Domain. Are use sure it is hexagonal at all?