The document discusses the advantages and disadvantages of monolithic architecture versus microservices, emphasizing the importance of understanding trade-offs in software development. It outlines essential rules for creating effective use cases and encapsulating business logic while advocating for a delayed decision-making approach in architecture. The conclusion highlights the benefits of well-built monoliths within the context of specific development needs and team dynamics.

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