The document discusses four architectural patterns: 1) Domain-driven design which focuses on structuring a system around the domain and collaborating with domain experts. 2) Command-query segregation which separates interfaces that mutate data from those that read data for clean and reusable code. 3) Command-query responsibility segregation which further separates systems for creating and reading data at a domain level. 4) Event sourcing which uses a series of events as the source of truth for a domain and materializes views from the event stream.

1. four architectural patterns
“ W H Y, S O M E T I M E S I ’ V E R E V I E W E D A S M A N Y A S
B E F O R E B R E A K FA S T ”

2. Slides Available: http://tinyurl.com/ArchiAlice

3. W H AT I S A N
“ A R C H I T E C T U R A L
PAT T E R N ”
• Enough ideas, rules and best
practices that stick together and form
a consistent approach to
development of systems.
• There is no one best or correct
pattern. It depends on your use case.
Some named ones may even be out
of favour.

4. “And what is the use of a book,” thought Alice, “without pictures or conversations?”
domain driven design

5. W H AT I S D O M A I N
D R I V E N D E S I G N ?
• Your system is formed organically
through consideration of the real-
world domain it exists in.
• Since all 300 of us do not want to do
this together, we can identify
subdomains and/or bounded contexts.
• This is discovered through
collaboration with domain experts and
the adoption of a “ubiquitous
language”

6. W H AT I S D O M A I N
D R I V E N D E S I G N ?
• It believes strongly in the layered architecture,
and defines what it thinks can exist in the
“domain” layer:
• Entity (things with state)
• Value Object (Immutable attributes)
• Aggregate (Cluster of objects treated as one
for data changes)
• Event (“something has happened”)
• Service, Repository, Factory (for managing
changing, retrieval or creation of any of the
above)

7. W H Y ?
• Reduces cost of communication
across different parts of the
organisation
• Minimises risk of significant
refactoring

8. “She generally gave herself very good advice, (though she very seldom followed it).”
command-query segregation

9. W H AT I S C Q S ?
• You should have some interfaces to
your system that mutate logic; and
some that read state.
• They should not mix.

10. W H Y ?
• Clean code
• Reusable code
• Self-documentation / Principle of
least surprise

11. “But it’s no use now,” thought poor Alice, “to pretend to be two people!
Why, there’s hardly enough of me left to make one respectable person!”
command-query
responsibility segregation

12. W H AT I S C Q R S ?
• You should have separate systems in
place for creating and reading data.
• This is more often used to describe
interfaces at a system or domain level

13. W H AT I S C Q R S ?
W R I T E R E A D
R E A D

14. W H Y ?
• (This is the most controversial of the
patterns presented today)
• Encourage re-use of APIs and
services
• Clear single source of truth for data
• Read and write can be scaled
independently

15. “I could tell you my adventures—beginning from this morning,” said Alice a little timidly
“but it’s no use going back to yesterday, because I was a different person then.”
event sourcing

16. W H AT I S E V E N T
S O U R C I N G ?
• The source of truth for your domain
is a series of events that tells the
system what state has changed.
• Any higher fidelity views are
“materialised” from this event stream
and are second class data citizen

17. W H Y ?
• Data restoration for free (if you treat
your events right)
• Audit log for free
• Can understand the state of a system
at a given time

18. “It seems very pretty,” she said when she had
finished it, “but it’s rather hard to understand!”
( Y O U S E E S H E D I D N ’ T L I K E T O C O N F E S S ,
E V E N T O H E R S E L F, T H AT S H E C O U L D N ’ T
M A K E I T O U T AT A L L . )

19. W H AT Y O U N E E D T O M O D E L …
D O M A I N
E V E N T S
C O M M A N D
E V E N T
• Requests by a user/system/etc. to change something
• Often written in the imperative mood
• Meaningful domain events - not just CRUD operations
• “Cancel Direct Debit”, “Onboard Customer”,
“Submit Meter Read”
• A notification that the state of the system has
explicitly changed (or that is hasn’t)
• Often written as participles
• Meaningful domain events - not just CRUD operations
• “Direct Debit Cancelled”, “Customer was not
onboarded”

20. W H AT Y O U N E E D T O M O D E L …
A G G R E G AT E S
C O M M A N D
E V E N T
• The aggregate contains the business logic to validate
a command, and understand the impact it should
have on the system.
• If you remember from DDD: Aggregate is a domain
entity. Domain entities should have the knowledge
internally to determine whether a command is
successful. (Clean Code, SOLID, Feature Envy etc.)
• The aggregate will be a noun, and could be
“Customer” or “CustomerAggregate”
• May be split up for ease, in which case the top-level
aggregate is an “aggregate root”.
E V E N T
E V E N T

21. W H AT Y O U N E E D T O M O D E L …
S A G A
E V E N T
E V E N T
• A saga is a state machine that manages processes
that span multiple services. These should still be
domain processes!
• The state of the saga is driven by the events that other
services generate. If the saga feels that a change is
needed based on the events, it can implement those
changes by issuing one or more commands.
• A saga should named after a business process, such
as “Account Creation” or “Account Creation Saga”
E V E N T
C O M M A N D

22. Z O O M I N G O U T…
A G G R E G AT E
W R I T E A P I
R E A D A P I
S A G A
E V E N T
S T O R E
M AT E R I A L I S E D
V I E W
M AT E R I A L I S E R
C O M M A N D

23. Z O O M I N G O U T…
A G G R E G AT E
W R I T E A P I
C O M M A N D
R E A D A P I
S A G A
E V E N T
S T O R E
M AT E R I A L I S E D
V I E W
M AT E R I A L I S E R

24. Z O O M I N G O U T…
A G G R E G AT E
W R I T E A P I
E V E N T
R E A D A P I
S A G A
E V E N T
S T O R E
M AT E R I A L I S E D
V I E W
M AT E R I A L I S E R
E V E N T
E V E N T

25. M AT E R I A L I S E R
Z O O M I N G O U T…
A G G R E G AT E
W R I T E A P I
E V E N T
R E A D A P I
S A G A
E V E N T
S T O R E
M AT E R I A L I S E D
V I E W
E V E N T
E V E N T
N E W R E C O R D

26. M AT E R I A L I S E R
Z O O M I N G O U T…
A G G R E G AT E
W R I T E A P I
R E A D A P I
S A G A
E V E N T
S T O R E
M AT E R I A L I S E D
V I E W
N E W R E C O R D

27. Z O O M I N G O U T…
A G G R E G AT E
W R I T E A P I
E V E N T
R E A D A P I
S A G A
E V E N T
S T O R E
M AT E R I A L I S E D
V I E W
M AT E R I A L I S E R
E V E N T
E V E N T

28. Z O O M I N G O U T…
A G G R E G AT E
W R I T E A P I
R E A D A P I
S A G A
E V E N T
S T O R E
M AT E R I A L I S E R
M AT E R I A L I S E D
V I E W
C O M M A N D

29. W H Y ?
• All the benefits of the other patterns
we’ve discussed
• Single, consolidated architecture that
scales nicely with the number of
teams
• Can spin up new microservices with
minimal cost down the line

30. “So she was considering in her own mind whether
the pleasure of making
a daisy-chain would
be worth the trouble
of getting up & picking the daisies...”

31. M I N I S T RY O F
J U S T I C E
• https://github.com/
CJSCommonPlatform/
microservice_framework_version_6
• Did the project succeed? Not really.
(And the consultancy behind was trashed in the news.)
• Did the architecture work? No.
Developers not good enough to
understand it, Ivory Tower Architecture
Function, 8 weeks to get words on a
screen.

32. M E T T L E
• Challenger bank targeting SMEs.
• Did the project succeed? Still going
strong. (And the consultancy behind was trashed
in the news.)
• Did it work? Kind of? After a bit of
wrangling. But we didn’t get half of
what it promised.

33. P E R S O N A L
P R O J E C T
• https://github.com/
SwamWithTurtles/decrypto-be/
• Did it work? Yeah, kinda but one
person projects are always doomed
to succeed.

34. Everything’s got a moral
(if only you can find it)