Learning Goal:
• Practice presenting architectural decisions and receive constructive feedback.
Detailed Content:
• Present mini project (10 min pitch)
• Q&A session with instructor and peers
• Receive improvement suggestions
• Discuss best practices and final wrap-up
The final step of this course brings everything together: you take the system you designed, the documentation you prepared, and the APIs you modeled—and present your architecture to others.
Each team should prepare a short, clear 10-minute pitch that tells a story. A good presentation answers:
What problem did you solve?
What does your system do?
How is it structured? Show your layered diagram or C4 diagram.
How do your RESTful APIs work?
What trade-offs or design choices did you face?
What did you learn in the process?
This is not about showing perfect code—it’s about showing that you can think, explain, and justify architectural decisions in a real-world way.
After each team’s pitch, open the floor for questions and discussion. Classmates and instructors can ask about:
Why you chose certain patterns (layered, MVC, microservices).
Why your API uses certain methods or status codes.
How your system would scale in the cloud.
What you would change if you had more time.
Answering questions helps you practice defending your choices, a key skill for real-world architects who must explain their designs to developers, managers, or clients.
No design is perfect—nor should it be! That’s why this final step focuses on constructive feedback. After the Q&A, the instructor and peers will share what worked well and where you can improve:
Are the diagrams clear and consistent?
Is the documentation easy to follow?
Are the REST APIs well-designed and RESTful?
Could the separation of layers or services be clearer?
Did you follow good principles for scalability, maintainability, and cost?
This feedback loop teaches you to see your own blind spots and strengthens your ability to refine your architecture in future projects.
To close the session, everyone comes together for a short wrap-up. The instructor can highlight common strengths seen across projects—clear API design, thoughtful layering, solid documentation—and point out recurring mistakes to watch out for in real jobs.
This final reflection ties the whole course together: theory, practice, teamwork, communication, and continuous improvement. You leave not just with a small system design, but with the confidence that you can plan, explain, and evolve architecture decisions collaboratively.
This final presentation isn’t just a grade—it’s a rehearsal for the real world, where good ideas only succeed when they are shared clearly, questioned honestly, and improved together. Practicing this skill now is one of the best ways to grow into an architect who builds systems that last—and teams that trust your judgment.