Skip to content
No description, website, or topics provided.
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
FlyWayFiles
VuelingExam
.gitignore
LICENSE
README.md

README.md

VuelingExam

Project TL; DR

What works

  • API authentication (JWT)
  • Logging (Serilog)
  • Dependency injection (Autofac)
  • All interfaces declared
  • Basic client repository integration and unit tests (failing due to lack of actual implementation)
  • Database migrations (FlyWay)
  • Basic DDD 3 layer structure
  • Custom exception filters on facade
  • Resource files (avoiding hardcoded strings)
  • Variable settings read from appsettings.json (avoiding hardcoded strings)
  • HTTP data fetching (parsing json and serializing it to a list)
  • Repository implementation
  • API Bussiness Logic

What's missing

  • Testing (integration, unit and behaviour) for the rest of the app
  • Actual code documentation

The project uses SOLID principles and CLEAN code rules whenever possible to aid in writing quality code.

Among other cool features, Autofac is used to inject our instances across the project at runtime and avoid depending on them at build time.

Logs are handled by Serilog which is implemented at runtime by autofac.

The initial data is fetched when starting the application using an HTTP Client and then stored in the database.

From there I want to use SQL Transactions in order to ensure that I can safely insert the fetched data. Using SQL transactions in the bussiness layer would save us from corrupting the database efectively executing a rollback if any of our operations, even across repositories, went wrong.

The project uses database versioning via FlyWay.

Environment

Hardware: Intel Core i7-8550U @ 1.80Ghz 2Ghz 64Bit, 8GB DDR3 RAM

OS: Windows 10 Pro 1809 (17763.316)

Software:

  • .NET Core 2.2.0
  • SQL Server 2015
  • VisualStudio Developer Edition 2017

Structure

The project is structured in 4 main layers shown in the following diagram

Initial DDD diagram

Project DDD diagram

Common Layer

Common layer has mainly shared code such as Models and Utilities. It should be used by any other layer as it is a cross layer.

Facade Layer (Bussiness Facade)

Bussiness Facade doesn't actually, and should not, implement any of our bussiness application. It only fires up the server (Kestrel) that will serve the API, implements the API controllers (which point to Bussiness Logic) and starts the Autofac chain of injection fown the line.

As this is the executing or runtime layer, appsettings.json is here as it's where it'll be read from.

Bussiness Layer (Bussiness Logic)

Bussines Layer implements Facade's layer controllers and other misc calculations or middlewares that don't get directly in touch with the database. This includes mainly fetching data from external APIs and controlling and handling repository requests coming from the Facade layer.

Repository Layer (Infrastructure)

The repository Layer, or DAO logic layer, implements all the logic that comunicates directly with the database. Including Authentication validation, which requires database access.

It's important to note that if we're to follow DDD rules, these layers, except for the common layer, should never comunicate with a layer that's not adjacent to them.

The Database

The database contains necesary tables that map to our models and our FlyWay versioning Schema.

On this particular setup, all Guid uniqueidentifiers are Primary Keys. The ClientId from the Policy model is a foreign key to the Client's ID, which relates both tables essentially allowing a search for Policies by user.

You can import the Client and Policy table structure using FlyWay by doing the following steps:

  • Copy the config file sotred under the FlyWayFiles directory to your FlyWay installation config folder.
  • Copy the .sql files stored under the FlyWayFiles/Sql directory to your FlyWay installation Sql folder.
  • Create VuelingExam database or execute CreateDatabase.sql
  • Run flyway migrate

Initial Database Client-Policy basic table structure (schema and ApiUser table not shown)

Database structure

Usage

Getting a token

Before using the API, you must register to recieve a token, you'll recieve a 401 Unauthorized error otherwise. In order to do so, send a json body containing

{
  "ID": "{user_guid}",
  "Name": "{user_name}",
  "Email": "{user_email}",
  "Role": "{user_role}"
}

to /api/Authentication/Login

If everything went well, you'll recieve your token. Once you have your token, add it in your Authorization header preceded by the word "Bearer".

AuthHeader

API Postman docs

Postman docs were generated manually using a posman collection. Link to docs

Swagger docs

Swagger docs are generated automatically by means of a NuGet extension. In order to document the API properly, I would have to use .NET's XML documentation features and add comments on top of each Controller method with its appropiete remarks and summaries.

License

This code is distributed under the MIT license.

Authors

Guillem Arias

You can’t perform that action at this time.