The document discusses the transition from microservices architecture to monolithic architecture. It outlines several rules and best practices for structuring applications, whether monolithic or separated into microservices. These include encapsulating business logic, hiding implementation details, extracting common components, and testing each layer independently. The document also addresses some of the trade-offs between the two architectures and considerations for when to "break" a monolith into microservices based on team size, requirements, or responsibilities. Overall it advocates understanding your specific context and optimizing decisions based on trade-offs rather than strictly following one architecture.
27. Rule 2: Encapsulate your business logic
● Create Objects with its own behaviour
● Instantiate/create them inside use cases
● Don’t expose their implementation
44. The purpose of a good architecture is to
defer decisions, delay decisions. The job
of an architect is not to make decisions,
the job of an architect is to build a
structure that allows decisions to be
delayed as long as possible. Why?
Because when you delay a decision,
you have more information when it
comes time to make it.
47. Break? When?
● The team is big enough
● Some slices have special requirements (performance,
computation...)
● Slices with different non-functional requirements
48. Conclusion
● Understand your context
● Study the trade-offs
● Optimize your decisions
● Rules for the win!
● Monoliths are so cool, if you know how to build them! :)