You’re reading the free preview.Unlock every conversation for €2.99
FreeFree previewChapter 6
Chapter 6 · Free preview
Backend Architecture
The Code Behind the Contract
What you will understand
- Apply the three-layer architecture (controller, service, repository)
- Explain dependency injection and how it improves testability
- Explain each SOLID principle in your own words with an example
- Weigh a monolith against microservices
- Design a DTO to move data between layers
Written by EduVerse for this preview; the slides below are the book’s own words.
Slides from the chapter
Each slide is a passage from the book with the figure or listing it talks about. Swipe, use the arrow keys or the buttons.
Slide 1 of 3
Separation of Concerns
6.2.1 · pp. 132–133
Conversation from The Software Realm, Decoded
Chapter 6 · 6.2.1 Separation of Concerns · pp. 132–133
Senior developer
Your code does five things: HTTP handling, validation, business logic, database access, email sending. When email provider changes, you touch the same function that handles HTTP. One change, five potential breaking points.
Peter
So... separate them?
Senior developer
Exactly. Three layers. Each with one job.
The pattern:
- Controller: Handles HTTP only
- Service: Handles business logic only
- Repository: Handles database only
Peter
Why three? Why not two or five?
Senior developer
Three is the sweet spot. Two is too mixed. Five is over-engineered. Think of it like a restaurant:
The restaurant analogy:
- Controller = Waiter: Takes orders, serves food. Doesn’t cook. Doesn’t decide recipes.
- Service = Chef: Decides what to cook, coordinates preparation. Doesn’t take orders. Doesn’t manage pantry.
- Repository = Pantry: Stores and retrieves ingredients. Doesn’t cook. Doesn’t serve.
Each person has one job. Waiter doesn’t need to know pantry organization. Chef doesn’t need to know table numbers.
What the book shows with it
Figure from The Software Realm, Decoded
Chapter 6 · 6.2.2 Controller: The HTTP Boundary · p. 133
That’s it.
Explore this table
Pick one to highlight it and read what the book says about it.
Other cells in the table (14)
Description
Table: 'Controller Responsibilities'. 'Does': extract data from the HTTP request, call the service layer, convert results to HTTP responses, map errors to HTTP status codes. 'Does NOT Do': business logic, direct database access, complex validation rules, long-running or heavy processing.
Description written by EduVerse; the figure itself is from the book.
The Complete Flow
6.2.5 · p. 134
Conversation from The Software Realm, Decoded
Chapter 6 · 6.2.5 The Complete Flow · p. 134
Peter’s realization
Each layer only talks to its neighbor! Controller never calls Repository directly.
Senior developer
Right. That separation makes everything testable and maintainable.
What the book shows with it
Figure from The Software Realm, Decoded
Chapter 6 · 6.2.5 The Complete Flow · p. 134
Peter traces a request through the layers:
Explore this figure
Pick one to highlight it and read what the book says about it.
Other labels in the figure (33)
Description
Flow diagram titled 'Request/Response Flow': left to right, 'Client (Browser/App)' sends 'HTTP POST' to 'Controller HTTP Handler', which calls 'create()' on 'Service Business Logic', which calls 'save()' on 'Repository Data Access', which sends 'SQL' to 'Database (PostgreSQL)'. Return arrows carry 'Rows', 'Entity', 'DTO' and '201' back. Notes label 'Entry Point', 'The Brain' and 'Data Layer'.
Description written by EduVerse; the figure itself is from the book.
Why DI Changes Everything
6.3.2 · p. 137
Conversation from The Software Realm, Decoded
Chapter 6 · 6.3.2 Why DI Changes Everything · p. 137
Senior developer
Think of electrical outlets. Your phone charger doesn’t care if power comes from solar, coal, or nuclear. Just knows: ’This outlet provides electricity.’
Peter’s code with DI
UserService doesn’t care if emails go through Gmail, Hotmail, SendGrid, or just get logged. Just knows: ’This thing can send emails.’
The contract: "Can send emails." The implementation: Up to configuration.
Peter
So Service depends on the interface (’can send emails’), not the implementation (’Gmail specifically’)?
Senior developer
Exactly. That’s Dependency Inversion. The D in SOLID.
Slide 1 of 3
Try it yourself
A simulation built by EduVerse around this chapter. It runs in your browser; nothing is sent anywhere.
The full chapter
This preview shows 5 of the chapter’s 27 passages. The full chapter has:
- 8 sections
- 14 conversations
- 5 figures and tables
- 3 What They Say boxes
- 7 knowledge-check questions
Sections in this chapter
- 6.1Peter's Architecture Journey Begins
- 6.2The Three-Layer Architecture
- 6.3The Dependency Problem
- 6.4SOLID Principles Through Peter's Refactoring
- 6.5The Security Disaster: Entities vs DTOs
- 6.6Monolith vs Microservices: Peter's Growing App
- 6.7Scaling: API Gateway and Beyond
- 6.8Peter's Takeaways