Definitivamente, los monolitos no están de moda. Cada vez cuesta más encontrar empresas que desarrollen sus aplicaciones como un monolito.
Lo que es peor, es que las que sí lo han hecho quieren migrar hacia arquitecturas distribuidas para solucionar, en teoría, los problemas derivados del monolito. ¿Por qué es eso? ¿Está el monolito acabado?
En esta charla veremos que no. Veremos que desarrollar un monolito mantenible, extensible, escalable y testeable es posible y está al alcance de todos.
Además, iremos un paso mas allá, y veremos que desarrollar un monolito con unas buenas prácticas puede facilitar mucho el paso a una arquitectura distribuida.
16. Pros
● Cheap communication: objects/modules vs systems
● Allows you to explore complexity and boundaries
● Easy to deploy
● Easy to start with the development
● Single database*
17. Cons
● Single point of failure
● Single database*
● Hard to scale*
● Hard to maintain*
● Huge test battery
25. Rule 2: Encapsulate your business logic
● Create Objects with its own behaviour
● Instantiate/create them inside use cases
● Don’t expose their implementation
42. 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.
45. Break? When?
● The team is big enough
● Some slices have special requirements (performance,
computation...)
● Slices with different non-functional requirements
46. 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! :)