21. Architecture basics

21.1. Introduction

The devonfw platform provides a solution to building applications which combine best-in-class frameworks and libraries as well as industry proven practices and code conventions. It massively speeds up development, reduces risks and helps you to deliver better results.

21.1.1. Overview Onion Design

This guide shows the overall proposed architecture in terms of separated layers making use the Onion architecture pattern. Each layers represents a logical group of components and functionality. In this guide you will learn the basics of the proposed architecture based in layers in order to develop software making use of the best practices.

21.1.2. Layer specification

It is important to understand the distinction between layers and tiers. Layers describe the logical groupings of the functionality and components in an application; whereas tiers describe the physical distribution of the functionality and components on separate servers, computers, networks, or remote locations. Although both layers and tiers use the same set of names (presentation, business, services, and data), remember that only tiers imply a physical separation. It is quite common to locate more than one layer on the same physical machine (the same tier). You can think of the term tier as referring to physical distribution patterns such as two-tier, three-tier, and n-tier.

— Layered Application Guidelines
MSDN Microsoft

The proposed architecture makes use of cooperating components called layers. Each layer contains a set of components capable to develop a specific functionality.

The next figure represents the different layers:

technical architecture
Figure 87. High level architecture representation

The layers are separated in physical tiers making use of interfaces. This pattern makes possible to be flexible in different kind of projects maximizing performance and deployment strategies (synchronous/asynchronous access, security, component deployment in different environments, microservices…​). Another important point is to provide automated unit testing or test-driven development (TDD) facilities.

Application layer

The Application Layer encapsulates the different .Net projects and its resource dependencies and manages the user interaction depending on the project’s nature.

technical architecture
Figure 88. Net application stack

The provided application template implements an dotnet API application. Also integrates by default the Swagger client. This provides the possibility to share the contract with external applications (angular, mobile apps, external services…​).

Business layer

The business layer implements the core functionality of the application and encapsulates the component’s logic. This layer provides the interface between the data transformation and the application exposition. This allow the data to be optimized and ready for different data consumers.

This layer may implement for each main entity the API controller, the entity related service and other classes to support the application logic.

In order to implement the service logic, the services class must follow the next specification:

    public class Service<TContext> : IService where TContext: DbContext

PE: devon4Net API template shows how to implement the TODOs service as follows:

    public class TodoService: Service<TodoContext>, ITodoService

Where Service is the base service class to be inherited and have full access for the Unit of work, TodoContext is the TODOs database context and ITodoService is the interface of the service, which exposes the public extended methods to be implemented.

Data layer

The data layer orchestrates the data obtained between the Domain Layer and the Business Layer. Also transforms the data to be used more efficiently between layers.

So, if a service needs the help of another service or repository, the implemented Dependency Injection is the solution to accomplish the task.

The main aim of this layer is to implement the repository for each entity. The repository’s interface is defined in the Domain layer.

In order to implement the repository logic, the repository class must follow the next specification:

    Repository<T> : IRepository<T> where T : class

PE: devon4Net API template shows how to implement the TODOs repository as follows:

    public class TodoRepository : Repository<Todos>, ITodoRepository

Where Repository is the the base repository class to be inherited and have full access for the basic CRUD operations, Todos is the entity defined in the database context. ITodoRepository is the interface of the repository, which exposes the public extended methods to be implemented.

Please remember that <T> is the mapped class which reference the entity from the database context. This abstraction allows to write services implementation with different database contexts
Domain layer

The domain layer provides access to data directly exposed from other systems. The main source is used to be a data base system. The provided template makes use of Entity Framework solution from Microsoft in order to achieve this functionality.

To make a good use of this technology, Repository Pattern has been implemented with the help of Unit Of Work pattern. Also, the use of generic types are makes this solution to be the most flexible.

Regarding to data base source, each entity is mapped as a class. Repository pattern allows to use this mapped classes to access the data base via Entity framework:

 public class UnitOfWork<TContext> : IUnitOfWork<TContext> where TContext : DbContext
Where <T> is the mapped class which reference the entity from the database.

The repository and unit of work patterns are create an abstraction layer between the data access layer and the business logic layer of an application.

Domain Layer has no dependencies with other layers. It contains the Entities, datasources and the Repository Interfaces.
devon4Net architecture layer implementaion

The next picture shows how the devon4Net API template implements the architectured described in previous points:

devon4Net api templare architecture implementation
Figure 89. devon4Net architecture implementations
Cross-Cutting concerns

Cross-cutting provides the implementation functionality that spans layers. Each functionality is implemented through components able to work stand alone. This approach provides better reusability and maintainability.

A common component set of cross cutting components include different types of functionality regarding to authentication, authorization, security, caching, configuration, logging, and communication.

21.1.3. Communication between Layers: Interfaces

The main target of the use of interfaces is to loose coupling between layers and minimize dependencies.

Public interfaces allow to hide implementation details of the components within the layers making use of dependency inversion.

In order to make this possible, we make use of Dependency Injection Pattern (implementation of dependency inversion) given by default in .Net Core.

The provided Data Layer contains the abstract classes to inherit from. All new repository and service classes must inherit from them, also the must implement their own interfaces.

technical architecture
Figure 90. Architecture representation in deep

21.1.4. Templates

State of the art

The provided bundle contains the devon4Net API template based on .net core. The template allows to create a microservice solution with minimal configuration.

Also, the devon4Net framework can be added to third party templates such as the Amazon API template to use lambdas in serverless envirnments.

Some features are:

  • Global configuration automated. devon4Net can be instantiated on any .net core application template with no effort

  • Support for HTTP2

  • Number of minium libraries needed

  • Modular clean Architecture layer

  • Red button functionality (aka killswitch) to stop attending API request with custom error

  • API error management via middleware

  • Support to only accept request from clients with a specific client certificate on Kestrel server. Special thanks to Bart Roozendaal (Capgemini NL)

  • All components use IOptions pattern to be set up properly

  • Swagger generation compatible con open api v3

    • Modules

  • The devon4Net netstandard libraries have been updated to netstandard 2.1

  • JWT:

    • Secured token encryption (token cannot be decrypted anymore by external parties). You can choose the encryption algorithm depending on your needs

    • Support for secret key or certificate encryption

    • Authorization available in the autogenerated swagger portal

  • Circuit breaker

    • Added support to bypass certificate validation

    • Support to use a certificate for https communications using Microsoft’s httpclient factory

  • Unit of Work

    • Repository classes unified for increasing performance and reduce the consumed memory

    • Support for different database servers: In memory, Cosmos, MySQL + MariaDB, Firebird, PostgreSQL, Oracle, SQLite, Access, MS Local.

Software stack
Table 22. Technology Stack of devon4Net
Topic Detail Implementation

runtime

language & VM

.Net Core Version 3.0

persistence

OR-mapper

Entity Framework Core

service

REST services

Web API

service - integration to external systems - optional

SOAP services

WCF

logging

framework

Serilog

validation

framework

NewtonSoft Json, DataAnnotations

component management

dependency injection

Unity

security

Authentication & Authorization

JWT .Net Security - Token based, local Authentication Provider

unit tests

framework

xUnit

Circuit breaker

framework, allows retry pattern on http calls

Polly

Target platforms

Thanks to the new .Net Core platform from Microsoft, the developed software can be published Windows, Linux, OS X and Android platforms.

The compete RID (Runtime Identifier) catalog is this:

  • Windows

    • Portable

      • win-x86

      • win-x64

    • Windows 7 / Windows Server 2008 R2

      • win7-x64

      • win7-x86

    • Windows 8 / Windows Server 2012

      • win8-x64

      • win8-x86

      • win8-arm

    • Windows 8.1 / Windows Server 2012 R2

      • win81-x64

      • win81-x86

      • win81-arm

    • Windows 10 / Windows Server 2016

      • win10-x64

      • win10-x86

      • win10-arm

      • win10-arm64

  • Linux

    • Portable

      • linux-x64

    • CentOS

      • centos-x64

      • centos.7-x64

    • Debian

      • debian-x64

      • debian.8-x64

    • Fedora

      • fedora-x64

      • fedora.24-x64

      • fedora.25-x64 (.NET Core 2.0 or later versions)

      • fedora.26-x64 (.NET Core 2.0 or later versions)

    • Gentoo (.NET Core 2.0 or later versions)

      • gentoo-x64

    • openSUSE

      • opensuse-x64

      • opensuse.42.1-x64

    • Oracle Linux

      • ol-x64

      • ol.7-x64

      • ol.7.0-x64

      • ol.7.1-x64

      • ol.7.2-x64

    • Red Hat Enterprise Linux

      • rhel-x64

      • rhel.6-x64 (.NET Core 2.0 or later versions)

      • rhel.7-x64

      • rhel.7.1-x64

      • rhel.7.2-x64

      • rhel.7.3-x64 (.NET Core 2.0 or later versions)

      • rhel.7.4-x64 (.NET Core 2.0 or later versions)

    • Tizen (.NET Core 2.0 or later versions)

      • tizen

    • Ubuntu

      • ubuntu-x64

      • ubuntu.14.04-x64

      • ubuntu.14.10-x64

      • ubuntu.15.04-x64

      • ubuntu.15.10-x64

      • ubuntu.16.04-x64

      • ubuntu.16.10-x64

    • Ubuntu derivatives

      • linuxmint.17-x64

      • linuxmint.17.1-x64

      • linuxmint.17.2-x64

      • linuxmint.17.3-x64

      • linuxmint.18-x64

      • linuxmint.18.1-x64 (.NET Core 2.0 or later versions)

  • OS X

    • osx-x64 (.NET Core 2.0 or later versions)

    • osx.10.10-x64

    • osx.10.11-x64

    • osx.10.12-x64 (.NET Core 1.1 or later versions)

  • Android

    • android

    • android.21

Last updated 2019-12-11 12:58:44 UTC