Clean, Tested, Microservices

Here begins a journey to get a better understanding of clean architecture within a microservice.

I see lots of methods clean architectural coding, and often, as a bit of a newbie to this area, I can never settle permanently on an idea.

I’m currently playing with this idea of a structure.

MyApp.Application
MyApp.Components
MyApp.Domain
MyApp.Infrastructure
MyApp.Persistance
MyApp.Services

A note about interfaces. I always struggle with the most commonsense place to put Interfaces. Should they sit next to the class? Should they be in their own library (to keep them separate)? I’m currently in a place where i put them in folders in the Application layer based upon their layers, so:

MyApp.Application
|-Interfaces
|-Persistance
|-Services

For me, the above method keeps all the Interfaces in one place, so I’m not hunting around for them when i need to find them.

MyApp.Domain

This layer is going to contain all the base classes used within the microservice. DTOs are kept within the application layer.

MyApp.Infrastructure

MyApp.Persistance

This layer is going to contain all the Repository classes used to communicate with the Database.

MyApp.Services

This layer is going to be used to initiate the microservice.

MyApp.Tests

This layer is going to contain all the tests for the microservice. And will be the starting focus for development within the MyApp microservice. Using TDD, I want to learn correctly how to write tests against Microservices and messaging systems.


Posted

in

,

by

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *