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.

1. De los microservicios al
monolito
Cristian Cotes
@ccotesg

2. Microservices

3. Cristian Cotes
ExperienceWho am I?

8. Contexts
● Responsibilities
● Motivation/goals
● Team
● Type of product
● Type of company

9. Everything is a trade-off

10. VS
Rápido y mal
Lento y bien

11. Rápido y bien

14. Microservices vs monolith
Call to other components
S4
S3
S5
S2S1
C1 C2

15. Microservices vs monolith
Contract changes
S4
S3
S5
S2S1
C1 C2

16. Microservices vs monolith
Deploy
S4
S3
S5
S2S1
C1 C2

17. Microservices vs monolith
Transactions
S4
S3
S5
S2S1
C1 C2
C3

18. Microservices vs monolith
Monitoring
S4
S3
S5
S2S1
C1 C2

20. Coding horror
(Some nice examples)

25. Rule 1: Create use cases
Examples:
● SendMessageUseCase
● EditMessageUseCase
● ForwardMessageUseCase
● ...

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

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

35. DomainApplicationInfrastructure
Repository
Implementation
HTTP server
Use Case Object / Entity

36. Infrastructure
Application
Domain

37. Rule 4: Create slices
Infrastructure
Application
Domain

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

39. Can I skip the rules?

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

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

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.

45. But...

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

49. De los microservicios al
monolito
Cristian Cotes
@ccotesg

50. One more thing...
● DDD complexity
● Domain services, domain events, aggregates…
● Frontend
● Frameworks
● ORM
● FP