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.

1. Mi Monolito Mola Mucho
Cristian Cotes
@ccotesg

2. #SCBCN18
Software Crafters Barcelona - VI Edition

5. Motivation

8. Monolith Microservices

10. Contexts
● Responsibilities: developer, lead, marketing, designer, CEO…
● Motivation/goals: learn, lead, reach users, style, money...
● Team: consolidated, new, growing…
● Type of product: MVP, prototype, stable…
● Type of company: startup, big enterprise, SMEs

11. Everything is a trade-off

12. VS
Rápido y mal
Lento y bien

13. Rápido y bien

15. What is a monolith?

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

18. Coding horror
(Some nice examples)

23. Rule 1: Create use cases
Examples:
● SendMessageUseCase
● EditMessageUseCase
● ForwardMessageUseCase
● CreateUserUseCase
● ActivateUserUseCase
● ...

25. Rule 2: Encapsulate your business logic
● Create Objects with its own behaviour
● Instantiate/create them inside use cases
● Don’t expose their implementation

28. Rule 3: Hide implementation details
● Database implementation
● Message brokers
● 3rd parties services
● Frameworks

33. DomainApplicationInfrastructure
Repository
Implementation
HTTP server
Use Case
Repository
Interface
Object / Entity

34. Infrastructure
Application
Domain

35. Rule 4: Create slices
Infrastructure
Application
Domain

36. Rule 5: Extract commonalities
● Common folder
● Future independent libraries

37. Can I skip the rules?

40. Testing
● Testing by layers
● Unit test
● Integration
● End-2-end

41. Database
● Each slice has its on database/schema
● Queries across slices?

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.

43. But...

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! :)

47. Mi Monolito Mola Mucho
Cristian Cotes
@ccotesg

48. One more thing...
● DDD complexity
● Domain services, domain events, aggregates…
● Frontend