Modular Monoliths @simonbrown An independent consultant - - PowerPoint PPT Presentation

▶
modular monoliths
SMART_READER_LITE
LIVE PREVIEW

Modular Monoliths @simonbrown An independent consultant - - PowerPoint PPT Presentation

May 27, 2023 456 likes •1.47k views

Modular Monoliths @simonbrown An independent consultant specialising in software architecture The Missing Chapter Also the creator of the Context C4 model, and Structurizr Containers Components Code The server-side of Structurizr is

slide-1
SLIDE 1 @simonbrown

Modular Monoliths

slide-2
SLIDE 2
slide-3
SLIDE 3
slide-4
SLIDE 4
slide-5
SLIDE 5

An independent consultant specialising in software architecture

slide-6
SLIDE 6

“The Missing Chapter”

slide-7
SLIDE 7 Also the creator of the C4 model, and Structurizr Context Containers Components Code
slide-8
SLIDE 8

The server-side of Structurizr is two Java/Spring modular monoliths, running on Pivotal Web Services’ Cloud Foundry PaaS

(i.e. no Docker, Kubernetes, etc)
slide-9
SLIDE 9

A well structured codebase is easy to visualise

slide-10
SLIDE 10

C4

Context, Containers, Components and Code - c4model.com
slide-11
SLIDE 11 Component diagram (level 3) Container diagram (level 2) Context diagram (level 1) Class diagram (level 4)
slide-12
SLIDE 12 Component diagram (level 3) Container diagram (level 2) Context diagram (level 1) Class diagram (level 4)
slide-13
SLIDE 13 Component diagram (level 3) Container diagram (level 2) Context diagram (level 1) Class diagram (level 4)
slide-14
SLIDE 14 Component diagram (level 3) Container diagram (level 2) Context diagram (level 1) Class diagram (level 4)
slide-15
SLIDE 15

Where’s my “component”?

(the “Tweet Component” doesn’t exist as a single thing; it’s a combination of interfaces and classes across a layered architecture)
slide-16
SLIDE 16

“ ”

“the component exists conceptually”

slide-17
SLIDE 17

Abstractions should reflect the code

slide-18
SLIDE 18

“model-code gap”

slide-19
SLIDE 19
slide-20
SLIDE 20

“ ”

Our architecture diagrams don’t match the code.

slide-21
SLIDE 21

“architecturally-evident coding style”

slide-22
SLIDE 22

The code structure should reflect the architectural intent

slide-23
SLIDE 23

Package by layer

slide-24
SLIDE 24

Organise code based upon what the code does from a technical perspective

slide-25
SLIDE 25

Package by layer is a “horizontal” slicing

slide-26
SLIDE 26 Web Business Data
slide-27
SLIDE 27

Relaxed vs strict layering

slide-28
SLIDE 28
slide-29
SLIDE 29
slide-30
SLIDE 30

Also sample codebases, starter projects, demos at conferences, etc…

slide-31
SLIDE 31

“ ”

Cargo cult programming can also refer to the results of applying a design pattern or coding style blindly without understanding the reasons behind that design principle.

https://en.wikipedia.org/wiki/Cargo_cult_programming
slide-32
SLIDE 32
slide-33
SLIDE 33
slide-34
SLIDE 34

Changes to a layered architecture usually result in changes across all layers

slide-35
SLIDE 35

Package by feature

slide-36
SLIDE 36

Organise code based upon what the code does from a functional perspective

slide-37
SLIDE 37

Features, domain concepts, aggregate roots, etc

slide-38
SLIDE 38

Package by feature is a “vertical” slicing

slide-39
SLIDE 39
slide-40
SLIDE 40

Cited benefits include higher cohesion, lower coupling, and related code is easier to find

slide-41
SLIDE 41

Ports and adapters

slide-42
SLIDE 42

Keep domain related code separate from technical details

slide-43
SLIDE 43

Variations on this theme include “hexagonal architecture”, “clean architecture”, “onion architecture”, etc

slide-44
SLIDE 44

The “inside” is technology agnostic, and is often described in terms

  • f a ubiquitous language
slide-45
SLIDE 45

The “outside” is technology specific

slide-46
SLIDE 46

The “outside” depends upon the “inside”

slide-47
SLIDE 47 Infrastructure (outside) Domain (inside)
slide-48
SLIDE 48 This approach is also “cargo culted”, yet not all frameworks are equal
slide-49
SLIDE 49

But…

slide-50
SLIDE 50

Hi, can you add feature X to the

  • rders functionality?
slide-51
SLIDE 51

Sure!

slide-52
SLIDE 52
slide-53
SLIDE 53

“ ”

A big ball of mud is a casually, even haphazardly, structured system. Its

  • rganization, if one can call it that,

is dictated more by expediency than design.

Big Ball of Mud Brian Foote and Joseph Yoder
slide-54
SLIDE 54

Architectural principles introduce consistency via constraints and guidelines

slide-55
SLIDE 55

“ ”

web controllers should never access repositories directly

slide-56
SLIDE 56

“ ”

we enforce this principle through good discipline and code reviews, because we trust our developers

slide-57
SLIDE 57

Responsible, professional software developers are still human :-)

slide-58
SLIDE 58

It’s 2018! In a world of artificial intelligence and machine learning, why don’t we use tools to help us build “good” software?

slide-59
SLIDE 59

“Fitness functions”

(e.g. cyclic complexity, coupling, etc)
slide-60
SLIDE 60

Tooling?

Static analysis tools, architecture violation checking, etc
slide-61
SLIDE 61

“ ”

types in package **/web should not access types in **/data

slide-62
SLIDE 62

Using tools to assert good code structure seems like a hack

slide-63
SLIDE 63

“ ”

But Java’s access modifiers are flawed…

slide-64
SLIDE 64

Package by component

slide-65
SLIDE 65

Organise code by bundling together everything related to a “component”

slide-66
SLIDE 66

Component?

a grouping of related functionality behind a nice clean interface, which resides inside an execution environment like an application
slide-67
SLIDE 67 A software system is made up of one or more containers, each of which contains one or more components, which in turn are implemented by one or more code elements. Code Code Code Component Component Component Container (e.g. client-side web app, server-side web app, console application, mobile app, microservice, database schema, file system, etc) Container (e.g. client-side web app, server-side web app, console applica mobile app, microservice, database schema, file system, etc Container . client-side web app, server-side web app, console application,
  • bile app, microservice, database schema, file system, etc)
Software System
slide-68
SLIDE 68
slide-69
SLIDE 69

Package by component is about applying component-based or service-oriented design thinking to a monolithic codebase

slide-70
SLIDE 70

Modularity as a principle

slide-71
SLIDE 71

Separating interface from implementation

slide-72
SLIDE 72

Impermeable boundaries

Access modifiers vs network boundaries Component Data Business Uses Microservice Data Business Uses Public API Public API
slide-73
SLIDE 73

The devil is in the implementation details

slide-74
SLIDE 74

public

slide-75
SLIDE 75

Organisation vs encapsulation

slide-76
SLIDE 76

If you make all types public, architectural styles can be conceptually different, but syntactically identical

slide-77
SLIDE 77
slide-78
SLIDE 78
slide-79
SLIDE 79
slide-80
SLIDE 80

Use encapsulation to minimise the number of potential dependencies

slide-81
SLIDE 81

The surface area of your internal public APIs should match your architectural intent

slide-82
SLIDE 82

If you’re building a monolithic application with a single codebase, try to use the compiler to enforce boundaries

slide-83
SLIDE 83

Or other decoupling modes such as a module framework that differentiates public from published types

slide-84
SLIDE 84

Or split the source code tree into multiple parts

slide-85
SLIDE 85 Infrastructure Domain
slide-86
SLIDE 86

There are real-world trade-offs with many source code trees

slide-87
SLIDE 87

And, more generally, each decoupling mode has different trade-offs

(modular monoliths vs microservices)
slide-88
SLIDE 88 A good architecture rarely happens through architecture-indifferent design
slide-89
SLIDE 89

Agility is a quality attribute

slide-90
SLIDE 90

A good architecture enables agility

slide-91
SLIDE 91 Monolithic big ball of mud Modular monolith Microservices Distributed big ball of mud Number of deployment units Modularity
slide-92
SLIDE 92
slide-93
SLIDE 93
slide-94
SLIDE 94

Class-Responsibility-Collaboration

Class Responsibilities Collaborators C l a s s R e s p
  • n
s i b i l i t i e s C
  • l
l a b
  • r
a t
  • r
s Class Responsibilities Collaborators
slide-95
SLIDE 95 Well-defined, in-process components is a stepping stone to out-of-process components (i.e. microservices) From components to microservices High cohesion Low coupling Focussed on a business capability Bounded context or aggregate Encapsulated data Substitutable Composable < All of that plus Individually deployable Individually upgradeable Individually replaceable Individually scalable Heterogeneous technology stacks
slide-96
SLIDE 96

Choose microservices for the benefits, not because your monolithic codebase is a mess

slide-97
SLIDE 97

Whatever architectural approach you choose, don’t forget about the implementation details

slide-98
SLIDE 98

Beware of the model-code gap

slide-99
SLIDE 99

Thank you!

simon.brown@codingthearchitecture.com @simonbrown