Skip to content

ReyStar/Orange.ApiTokenValidation

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

33 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Orange.ApiTokenValidation

license Build Status

Project target

The main target of this simple project must show how implement hexagonal architecture in practice, use repository pattern with Dapper, .Net Core Web API with versioning and write metrics and logs. This project should be considered as just for fun) if u can find some interesting for u I will very happy!

Additional description will be soon ...

Architecture of the project

The hexagonal architecture, or ports and adapters architecture, is an architectural pattern used in software design. It aims at creating loosely coupled application components that can be easily connected to their software environment by means of ports and adapters. This makes components exchangeable at any level and facilitates test automation. The hexagonal architecture directs all dependencies to the center of the external infrastructure adapters in the domain layer. Hexagonal.png The following architectural layers are usually distinguished:

  • Domain layer - completely independent of other levels. Contains data models and the business logic inherent in these models.
  • Domain services layer - layer that contains pure logic for working with domain objects without using port interfaces. This layer is quite ephemeral and in practice many developers aren't separete it as a separate layer and combine it with the domain layer.
  • Application layer - depends on the domain level and sometimes on the Domain service layer. Layer containing the business rules of the application and if u use a micro-service approach with DDD principles, this layer essentially implements the business logic of our bounded context also contains the definition of port interfaces and never refers to specific frameworks. This layer invokes the infrastructure using the port interface. In practice, when designing a service for a micro-service architecture, it doesn't make much sense to separate the domain layer and the domain services layer from the application layer.
  • Infrastructure layer - it level depends on all levels located above it. It layer implements adapters for the interfaces of ports. This level can be considered as a plug-in to the application level, it can be easily replaced with another one in case of infrastructure changes, since the levels above don't have any strong coupling with it. I don't agree with some colleagues who separate the user interface layer from the infrastructure layer. I wouldn't do that.
  • Actors - are participants that interact with the application. It can be real users who connect using ui or other applications/services. Usually exist two Actors types: Primary/Driving Actors (web ui, console, etc...) and Secondary Actors are db, message queue or other external systems that other Primary/Driving Actors use.
  • Core Domain - is an architecture unit that can be reused in multiple applications. I have found references to it in several sources, but I do not consider it possible to apply it in practice, when working with the DDD approach and microservices, since Core Domain must go beyond the bounded context.

Monitoring and Alerting

To check the health of this application and the infrastructure as a whole, I use prometheus and prometheus alert manager and the Victoria metrics time series database. Usually applications that use Prometheus use the pull model to collect metrics. I use the push model as an example of its application, but I don't recommend using this model in production.

Correlation Id

To track requests through the service hierarchy, the Correlation Id header is used. To automatically transfer it to child services, ASP net core using HeaderPropagation middleware. If Correlation Id header doesn't exist it will generated by CorrelationIdMiddleware.

TODO list

  • Add Vault manager for secrets and protect sensitive data by HashiCorp use VaultSharp or other alternative client or service
  • Add embedded NoSQL database like LiteDB. This for testing a very interesting approach where data is distributed across a group of services, rather than services being distributed across a group of databases.
  • Add kubernetes yaml configuration for azure and aws.

Infrastructure for testing

If u want to see how it work u can build project Orange.ApiTokenValidation.Shell.csproj from src directory then run docker-compose.yml file. For testing u can use next web endpoints:

About

No description, website, or topics provided.

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages