Disclaimer:
Don’t do micro-
services like this!
…unless you know exactly what you are doing.
Slide 4
Slide 4 text
No content
Slide 5
Slide 5 text
If you can't build a monolith,
what makes you think
microservices are the answer?
Simon Brown
http://www.codingthearchitecture.com/2014/07/06/distributed_big_balls_of_mud.html
Slide 6
Slide 6 text
“Monolith First”
This pattern has led many of my colleagues to argue that
you shouldn't start a new project with microservices,
even if you're sure your application will be big enough to
make it worthwhile.
Martin Fowler
http://martinfowler.com/bliki/MonolithFirst.html
Slide 7
Slide 7 text
Don’t start with a monolith
… when your goal is a microservices architecture
Stefan Tilkov
http://martinfowler.com/articles/dont-start-monolith.html
Slide 8
Slide 8 text
No content
Slide 9
Slide 9 text
A good, simple software
design creates options
http://quickglance.at/en/simple_design/changes_and_simplicity
The basic assumption for this talk:
Slide 10
Slide 10 text
e.g.
The option to change your software
from monolith to micro services
later…
Slide 11
Slide 11 text
e.g. Open / Closed Principle
“Software entities (classes, modules,
functions, etc.) should be open for extension,
but closed for modification“
Slide 12
Slide 12 text
e.g. Open / Closed Principle
Paraphrased:
“I want to be able to add functionality
without changing any existing code“
Like: Adding the option to deploy the system as a set of micro services
to a monolithic software.
Slide 13
Slide 13 text
Topics for today
• The SOLID Principles
• The Four Rules of Simple Design
• DDD
• CQRS
• Monoliths / Micro Services
• Spring Boot
• Big / Some / No Design Upfront
Slide 14
Slide 14 text
Commercial Break ;)
David Tanzer (@dtanzer)
[email protected]
I help my clients to:
• Work together more effectively as a team
• Improve their technical practices
• Improve their software quality / design
• Re-gain control of their legacy code
http://davidtanzer.net
Slide 15
Slide 15 text
Example App:
Twitt… ahm… Microblogging
Slide 16
Slide 16 text
Demo…
Slide 17
Slide 17 text
No content
Slide 18
Slide 18 text
Should reads go through the
domain model?
(Spoiler: Probably not)
Slide 19
Slide 19 text
If you don’t want to create an
“anemic domain model”, your
domain model might get quite
complicated…
https://en.wikipedia.org/wiki/Anemic_domain_model
Slide 20
Slide 20 text
No content
Slide 21
Slide 21 text
Problems
• Data is read/processed more often that it is written (in many apps)
• Mapping the domain model to the DB
• Re-creating the domain model from the DB
• Translating domain model to / from UI data
Slide 22
Slide 22 text
No content
Slide 23
Slide 23 text
Problems / Disadvantages?
Slide 24
Slide 24 text
CQRS
Command / Query Responsibility Segregation
Slide 25
Slide 25 text
No content
Slide 26
Slide 26 text
How can we create the query models?
e.g. Event Sourcing
Slide 27
Slide 27 text
No content
Slide 28
Slide 28 text
No content
Slide 29
Slide 29 text
Where are the components?
Let’s try to improve the design a bit more…
Slide 30
Slide 30 text
The SOLID Principles
Slide 31
Slide 31 text
Single Responsibility Principle
“Every module or class should have responsibility over a single
part of the functionality provided by the software, and that
responsibility should be entirely encapsulated by the class.“
“A class should have only one reason to
change.”
Slide 32
Slide 32 text
Open / Closed Principle
“Software entities (classes, modules, functions, etc.) should be
open for extension, but closed for modification“
“I want to be able to add functionality
without changing any existing code“
Slide 33
Slide 33 text
Liskov Substitution Principle
“If S is a subtype of T, then objects of type T may be replaced
with objects of type S (i.e. objects of type S may substitute
objects of type T) without altering any of the desirable
properties of that program (correctness, task performed,
etc.)“
“Subclasses should not override behavior in
an incompatible way“
Slide 34
Slide 34 text
Interface Segregation Principle
“No client should be forced to depend on methods it does not
use.“
“The consumer defines what it needs from
an interface. Every consumer gets their own
interface.“
Slide 35
Slide 35 text
Dependency Inversion Principle
“High-level modules should not depend on low-level modules.
Both should depend on abstractions. Abstractions should not
depend on details. Details should depend on abstractions.“
“Your business logic should not depend on
your infrastructure code.“
Slide 36
Slide 36 text
No content
Slide 37
Slide 37 text
No content
Slide 38
Slide 38 text
The Four Rules of Simple Design
Slide 39
Slide 39 text
Design that is simple…
• …passes it’s tests.
• …maximizes clarity.
• …minimizes duplication.
• …has fewer elements.
http://quickglance.at/en/simple_design/overview
Slide 40
Slide 40 text
What does this have to do with
micro services?
Slide 41
Slide 41 text
A good, simple software
design creates options
http://quickglance.at/en/simple_design/changes_and_simplicity
The basic assumption for this talk:
Slide 42
Slide 42 text
Monolith: Wire dependencies
directly at runtime (Spring, Guice,
by hand, …)
Slide 43
Slide 43 text
No content
Slide 44
Slide 44 text
Micro Services: Wire
communication stubs instead of
service classes.
Slide 45
Slide 45 text
No content
Slide 46
Slide 46 text
Bringing it all together
with...
• Spring Boot
• Flyway
• An un-orthodox project structure
Slide 47
Slide 47 text
No content
Slide 48
Slide 48 text
No content
Slide 49
Slide 49 text
Demo…
Slide 50
Slide 50 text
Thank You!
David Tanzer (@dtanzer)
[email protected]
I help my clients to:
• Work together more efficiently as a team
• Improve their technical practices
• Improve their software quality / design
• Re-gain control of their legacy code
http://davidtanzer.net