Clean Architecture in golang

Internal tech talk

Transcript

1. Clean architecture
2. Flexibility
3. “Everything should be made as simple as possible, but not simpler.” - Albert Einstein Culture
4. Go
5. 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
6. 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
7. Domain It’s where we keep the business logic of uniplaces. No change in the upper layers should affect the domain layer. Architecture Architecture
8. Usecase This layer contains application specific logic. This use cases orchestrate the flow of data to and from the entities. Architecture Architecture
9. 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
10. 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
11. Profiles app
12. Identify your use cases
13. - I want to get an account by username getAccountByUsername();
14. Start by writing a failing test
15. I know I’ll need to get the account from somewhere
16. I know I’ll need to get the account from somewhere I know I want to return an account domain object
17. I know I’ll need to get the account from somewhere Create the interactor I know why want to return an account domain object
18. 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
19. Test fails of course because nothing is written
20. Architecture Use case layer has interactors
21. Architecture Use case layer has interactors This doesn’t exist yet, and I don’t give a shit!
22. Test passing, good
24. You know what ?!?!?!
25. 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
26. Clean / SCREAM architecture
27. I can tell my app is something about accounts
28. But tests doesn’t give value to our users, let’s implement
29. 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
30. 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
31. 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
32. Pretty, but still not giving anything to users
33. 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
34. Delivery layer
35. CLI command ?
36. RPC ?
37. HTTP API ?
38. 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
39. 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
40. Adding more delivery mechanisms?
41. 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
42. Use the same interactors
43. Wiring everything
44. Architecture Dependency graph