Clean Architecture in golang

Slide 1

Slide 1 text

Clean architecture

Slide 2

Slide 2 text

Flexibility

Slide 3

Slide 3 text

“Everything should be made as simple as possible, but not simpler.” - Albert Einstein Culture

Slide 4

Slide 4 text

Slide 5

Slide 5 text

The concentric circles represent different areas of software. In general, the further out you go, the higher level the software becomes. The outer circles are mechanisms. The inner circles are policies. Architecture Architecture

Slide 6

Slide 6 text

The dependency rule The overriding rule that makes this architecture work is The Dependency Rule. This rule says that source code dependencies can only point inwards. Nothing in an inner circle can know anything at all about the implementation of something in an outer circle. Architecture Architecture

Slide 7

Slide 7 text

Domain It’s where we keep the business logic of uniplaces. No change in the upper layers should affect the domain layer. Architecture Architecture

Slide 8

Slide 8 text

Usecase This layer contains application specific logic. This use cases orchestrate the flow of data to and from the entities. Architecture Architecture

Slide 9

Slide 9 text

Delivery / Adapters This layer is where we define our delivery mechanisms. Is it HTTP ? CLI ? Every mechanism and their dependencies should be placed in this layer. Architecture Architecture

Slide 10

Slide 10 text

Infrastructure This layer is where the details go. Database implementations for instance are placed here. This layer is the upper one, so it may know about internal layers. Architecture Architecture

Slide 11

Slide 11 text

Profiles app

Slide 12

Slide 12 text

Identify your use cases

Slide 13

Slide 13 text

- I want to get an account by username getAccountByUsername();

Slide 14

Slide 14 text

Start by writing a failing test

Slide 15

Slide 15 text

I know I’ll need to get the account from somewhere

Slide 16

Slide 16 text

I know I’ll need to get the account from somewhere I know I want to return an account domain object

Slide 17

Slide 17 text

I know I’ll need to get the account from somewhere Create the interactor I know why want to return an account domain object

Slide 18

Slide 18 text

I know I’ll need to get the account from somewhere Create the interactor I know why want to return an account domain object And this is the function signature I want to have

Slide 19

Slide 19 text

Test fails of course because nothing is written

Slide 20

Slide 20 text

Architecture Use case layer has interactors

Slide 21

Slide 21 text

Architecture Use case layer has interactors This doesn’t exist yet, and I don’t give a shit!

Slide 22

Slide 22 text

Test passing, good

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

You know what ?!?!?!

Slide 25

Slide 25 text

Directory structure All use case implementations are in this folder. Note the usecase/repository it has the interface adapter to plug with some repository implementation. Architecture 1. Use case layer

Slide 26

Slide 26 text

Clean / SCREAM architecture

Slide 27

Slide 27 text

I can tell my app is something about accounts

Slide 28

Slide 28 text

But tests doesn’t give value to our users, let’s implement

Slide 29

Slide 29 text

Architecture Plugging the repos I want to use dynamo Dynamo will return some random data structure, but the repo needs to return a domain “object” Just fetch, transform and return what’s expected

Slide 30

Slide 30 text

Directory All implementations of external resources are to be placed in this directory. Interface adapters to access this layer will be placed in its own directory. Architecture Infrastructure

Slide 31

Slide 31 text

Architecture I know my domain is about accounts I know the use cases my app has, but by looking at the use cases I don’t know how i’m getting / saving stuff Here I know what technologies I’m actually using, which is dynamo. Current project structure

Slide 32

Slide 32 text

Pretty, but still not giving anything to users

Slide 33

Slide 33 text

Infrastructure This layer is where the details go. Database implementations for instance are placed here. This layer is the upper one, so it may know about internal layers. Architecture Delivery mechanism Now let’s choose how we want to deliver to our users

Slide 34

Slide 34 text

Delivery layer

Slide 35

Slide 35 text

CLI command ?

Slide 36

Slide 36 text

RPC ?

Slide 37

Slide 37 text

HTTP API ?

Slide 38

Slide 38 text

Here we’re having everything that’s related to the HTTP delivery method. That’s why you see things like tokens, middlewares, payload etc Architecture Delivery layer

Slide 39

Slide 39 text

Here we’re having everything that’s related to the HTTP delivery method. That’s why you see things like tokens, middlewares, payload etc Architecture Delivery layer Communicate with the inner layer from the interface’s

Slide 40

Slide 40 text

Adding more delivery mechanisms?

Slide 41

Slide 41 text

delivery/rpc Will use all the layers below that are already implemented, so we just need to focus on the RPC itself. Architecture Just add an RPC delivery mechanism