SOLID Monoliths / Microservices

What if deploying a system as a monolith as a set of microservices was just an implementation detail? Can we create this option by designing the system well?

Transcript

1. SOLID Monoliths / Microservices
2. This is not a “Micro Services” talk (mostly)
3. Disclaimer: Don’t do micro- services like this! …unless you know exactly what you are doing.
5. 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
6. “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
7. Don’t start with a monolith … when your goal is a microservices architecture Stefan Tilkov http://martinfowler.com/articles/dont-start-monolith.html
9. A good, simple software design creates options http://quickglance.at/en/simple_design/changes_and_simplicity The basic assumption for this talk:
10. e.g. The option to change your software from monolith to micro services later…
11. e.g. Open / Closed Principle “Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification“
12. 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.
13. Topics for today • The SOLID Principles • The Four Rules of Simple Design • DDD • CQRS • Monoliths / Micro Services • Spring Boot • Big / Some / No Design Upfront
14. Commercial Break ;) David Tanzer (@dtanzer) business@davidtanzer.net 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
15. Example App: Twitt… ahm… Microblogging
16. Demo…
18. Should reads go through the domain model? (Spoiler: Probably not)
19. 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
21. 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
23. Problems / Disadvantages?
24. CQRS Command / Query Responsibility Segregation
26. How can we create the query models? e.g. Event Sourcing
29. Where are the components? Let’s try to improve the design a bit more…
30. The SOLID Principles
31. 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.”
32. 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“
33. 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“
34. 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.“
35. 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.“
38. The Four Rules of Simple Design
39. Design that is simple… • …passes it’s tests. • …maximizes clarity. • …minimizes duplication. • …has fewer elements. http://quickglance.at/en/simple_design/overview
40. What does this have to do with micro services?
41. A good, simple software design creates options http://quickglance.at/en/simple_design/changes_and_simplicity The basic assumption for this talk:
42. Monolith: Wire dependencies directly at runtime (Spring, Guice, by hand, …)
44. Micro Services: Wire communication stubs instead of service classes.
46. Bringing it all together with... • Spring Boot • Flyway • An un-orthodox project structure
49. Demo…
50. Thank You! David Tanzer (@dtanzer) business@davidtanzer.net 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