Let's build components, not layers

Slide 1

Slide 1 text

TOM HOMBERGS | SENIOR SOFTWARE ENGINEER | @TOMHOMBERGS Let’s build components, not layers Component-based architecture with Spring

Slide 2

Slide 2 text

Software is over- engineered Software is under- engineered Software is over- engineered Software is under- engineered

Slide 3

Slide 3 text

Software is over- engineered Software is under- engineered (at the code level) (at the system level) Software is over- engineered Software is under- engineered

Slide 4

Slide 4 text

Software is over- engineered Software is under- engineered MONOLITH MICROSERVICES Software is over- engineered Software is under- engineered (at the code level) (at the system level)

Slide 5

Slide 5 text

How can I organise my code to support a modular monolith*? LEAD QUESTION * monolith = a deployment unit that covers more than one bounded context

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

Tom Hombergs “You can’t just keep it simple. Make it simple, then it’s easy.” re fl ectoring.io

Slide 9

Slide 9 text

Agenda Why organise code? What’s wrong with layers? What’s wrong with verticals? Clean / Hexagonal architecture? Component-based architecture! Field study

Slide 10

Slide 10 text

Where is this feature in the code? How can I replace this part of the code? What is this part of the code doing? How can I move this feature from this codebase to another? What can break if I modify this part of the code? Where do I add this new feature to the code? Who is using this part of the code? How does this code fit into the overall architecture?

Slide 11

Slide 11 text

Goals of code organisation Understandability Easy to navigate the codebase. Get onboarded quicker. And more … What do you want from good code organisation? Maintainability Easy to keep the codebase in a good shape. Evolvability Easy to add to / remove from / modify the codebase.

Slide 12

Slide 12 text

Agenda Why organise code? What’s wrong with layers? What’s wrong with verticals? Clean / Hexagonal architecture? Component-based architecture! Field study

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

What’s wrong with layers? Blurred boundaries Mental capacity Horizontal dependencies everywhere The only rule is that dependencies may not go to a layer above. This means that a lot of horizontal dependencies creep in over time. The business use cases are hidden Use cases are often hidden in very broad services within the business layer and are hard to fi nd and reason about.

Slide 15

Slide 15 text

What’s wrong with layers? Architecture / code gap A codebase with 3 layers has 3 high-level components to reason about. The actual architecture is more complex and not evident from looking at the code. We have to do mental mapping continuously. A layer is doing too much We can’t grasp what a layer is doing because it’s too broad. Our brain can only process a couple of concepts at the same time (my brain, at least). Blurred boundaries Mental capacity

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

Agenda Why organise code? What’s wrong with layers? What’s wrong with verticals? Clean / Hexagonal architecture? Component-based architecture! Field study

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

What’s wrong with slices? Slices have a large surface area Slices don’t have a dedicated API, making all dependencies to other slices fair game. Limited evolvability Large surface area

Slide 20

Slide 20 text

What’s wrong with slices? Limited evolvability Large surface area Replacing or removing a slice is risky Moving a slice out of the codebase is hard due to accidental dependencies.

Slide 21

Slide 21 text

No content

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

Agenda Why organise code? What’s wrong with layers? What’s wrong with verticals? Clean / Hexagonal architecture? Component-based architecture! Field study

Slide 25

Slide 25 text

Clean Architecture

Slide 26

Slide 26 text

Hexagonal Architecture

Slide 27

Slide 27 text

It’s great for a rich domain model CLEAN / HEXAGONAL ARCHITECTURE

Slide 28

Slide 28 text

We often don’t have a rich domain model! It’s great for a rich domain model CLEAN / HEXAGONAL ARCHITECTURE

Slide 29

Slide 29 text

Everybody interprets it differently CLEAN / HEXAGONAL ARCHITECTURE

Slide 30

Slide 30 text

We need simplicity! Everybody interprets it differently CLEAN / HEXAGONAL ARCHITECTURE

Slide 31

Slide 31 text

Is there a simple architecture without the overhead?

Slide 32

Slide 32 text

Agenda Why organise code? What’s wrong with layers? What’s wrong with verticals? Clean / Hexagonal architecture? Component-based architecture! Field study

Slide 33

Slide 33 text

COMPONENTS

Slide 34

Slide 34 text

COMPONENTS

Slide 35

Slide 35 text

Namespace Each component has a unique namespace. API Each component has a dedicated API package. Internal Each component has a dedicated “internal” package. Nesting It’s components all the way down. Component rules

Slide 36

Slide 36 text

Namespace Each component has a unique namespace.

Slide 37

Slide 37 text

Namespace Each component has a unique namespace.

Slide 38

Slide 38 text

Namespace Each component has a unique namespace.

Slide 39

Slide 39 text

API Each component has a dedicated API package. Internal Each component has a dedicated “internal” package.

Slide 40

Slide 40 text

Nesting It’s components all the way down.

Slide 41

Slide 41 text

Nesting It’s components all the way down.

Slide 42

Slide 42 text

Nesting It’s components all the way down.

Slide 43

Slide 43 text

Nesting It’s components all the way down. implements

Slide 44

Slide 44 text

Nesting It’s components all the way down.

Slide 45

Slide 45 text

Nesting It’s components all the way down. implements

Slide 46

Slide 46 text

Agenda Why organise code? What’s wrong with layers? What’s wrong with verticals? Clean / Hexagonal architecture? Component-based architecture! Field study

Slide 47

Slide 47 text

Schedule checks Checks should be queued Execute checks Dequeues and executes checks Store check results Stores check results in the database Retrieve check results Provides an API to retrieve check results Building a “check engine” component

Slide 48

Slide 48 text

Building a “check engine” component Execute checks Store check results Retrieve check results Schedule checks

Slide 49

Slide 49 text

Namespace

Slide 50

Slide 50 text

API & Internal packages

Slide 51

Slide 51 text

API to schedule checks Schedule checks Checks should be queued

Slide 52

Slide 52 text

API to query check results Retrieve check results Provides an API to retrieve check results

Slide 53

Slide 53 text

Sub-component for running checks Execute checks Dequeues and executes checks

Slide 54

Slide 54 text

Sub-component for database storage Store check results Stores check results in the database Retrieve check results Provides an API to retrieve check results

Slide 55

Slide 55 text

Sub-component for queueing and dequeueing checks Schedule checks Checks should be queued

Slide 56

Slide 56 text

Con fi guration to load all Spring beans of the top- level component into the application context

Slide 57

Slide 57 text

Auto-load the con fi guration when “check-engine” component is in the classpath

Slide 58

Slide 58 text

External API to schedule a check Schedule checks Checks should be queued implements

Slide 59

Slide 59 text

No API package because the API is exposed by the parent component! Schedule checks Checks should be queued

Slide 60

Slide 60 text

Con fi guration to load all Spring beans of the nested component into the application context Schedule checks Checks should be queued

Slide 61

Slide 61 text

Internal API to store check results implements calls Store check results Stores check results in the database

Slide 62

Slide 62 text

Internal API to run checks calls Execute checks Dequeues and executes checks implements

Slide 63

Slide 63 text

External API to retrieve check results implements Retrieve check results Provides an API to retrieve check results

Slide 64

Slide 64 text

Why build components? Maintainability Understand- ability Evolvability Easily bridge the architecture / code gap Minimal mental mapping from the architecture to the code and back.

Slide 65

Slide 65 text

Why build components? Maintainability Understand- ability Evolvability Easily enforce dependencies One simple dependency rule: no access to an internal package from outside of that package.

Slide 66

Slide 66 text

Why build components? Maintainability Understand- ability Evolvability Easily move code around Thanks to narrow API surfaces and clear dependencies, code is easy to move around within the codebase or to another codebase.

Slide 67

Slide 67 text

No content

Slide 68

Slide 68 text

re fl ectoring.io/spring-io re fl ectoring.io/java-components-clean-boundaries/ Thank you for your patience!

Slide 69

Slide 69 text

No content