You have reached the end. You started this course with a seemingly simple question — what is a design pattern? — and you finish it having built, piece by piece, a complete food delivery platform: PideYa. What began as a global configuration object and an email notifier is now, in your head, a system with a composable menu, an orchestrated checkout, orders with a lifecycle, coordinated delivery, and even a distributed version with its sagas and circuit breakers. This final lesson introduces nothing new: it looks back to lock in the essentials, gives you a yardstick for self-assessment, and proposes the first 90 days of the road ahead.

1. The full journey: PideYa as a mirror
2. The 7 core ideas of the course
3. Final self-assessment: you know X if you can Y
4. Next steps: a 90-day path
5. Farewell

Every module of the course left its layer on PideYa. Walking through them in order is walking through the maturity curve of any software designer:

Read it top to bottom and you will see the complete narrative: from the definition of a pattern to a well-designed monolith, and from the well-designed monolith to the distributed platform. That order was no accident: nobody designs a distributed system well without first having designed an object well.

If five years from now you remember only seven sentences from this course, let them be these:

1. Patterns are intents, not templates. Copying Strategy's UML diagram is not applying Strategy; applying it is recognizing "there is a family of interchangeable algorithms here". That is why the same pattern fits in three lines with lambdas or in five classes.
2. Composition over inheritance. The silent lesson behind Decorator, Strategy, Bridge, and half a dozen more: wrapping and delegating buys flexibility at runtime; inheriting locks in decisions at compile time. The extras on a PideYa dish proved it better than any theory.
3. Wait until it hurts. A pattern gets introduced when the code asks for it — the third if on the delivery type, the second notification channel — not on day one "just in case". Over-engineering is the dark side of this catalog, and refactoring toward patterns is its antidote.
4. The name matters. Saying "this is an Adapter" in a code review conveys, in two words, a problem, a solution, and its consequences. The shared vocabulary is, day to day, the highest-return benefit of everything you have studied.
5. Program to an interface, not an implementation. The 1994 principle that underpins everything from Factory Method to Spring's dependency injection to the ports of hexagonal architecture. One idea, thirty years of relevance.
6. All design is a trade-off. Every pattern buys flexibility by paying in indirection; every microservice buys autonomy by paying in distributed complexity. There is no good solution in the abstract: there is the right one for a context, and the context changes.
7. Catalogs grow, but intents endure. Circuit Breaker is a Proxy that protects; API Gateway, a Facade over the network; the Outbox, a consistency problem in new clothes. Whoever masters the intents learns each new pattern in minutes — which is why this course also serves you for the patterns that have not been invented yet.

Design knowledge is not measured by reciting definitions but by doing. Go through this list honestly; every "no" is simply your next practice goal:

If you checked most of them, you don't just "know the patterns": you think in patterns, which was the real goal from the very first lesson.

The biggest risk at the end of a course is the void of the day after. A concrete proposal, adjustable to your pace (assumes 4-6 hours a week):

Three rules so the plan survives contact with reality: every week ends with an artifact (a commit, a note, an ADR — not just reading); if a week falls through, you pick it back up without guilt and without "starting over"; and on day 90, you decide the next cycle yourself — you now have the judgment and the resource map to do it.

• Mistake: closing the course and not writing code for a month. What you learned degrades fast without immediate practice. The 90-day plan exists precisely for this: start this week, even if it's just one hour.
• Mistake: becoming the team's "patterns evangelist". With a freshly learned hammer, everything looks like a nail. Remember module 5: the best designer is the one who knows when not to apply the pattern, and the vocabulary is for conversing, not for pronouncing verdicts.
• Mistake: measuring progress by content consumed. Books read and videos watched are not the metric; the metric is the self-assessment table: what can you do today that you couldn't three months ago.
• Tip: come back to this course as a reference. The comparison lessons in modules 2, 3, and 4 and the selection method in module 5 are designed to be reread with a real problem in hand — that is how a catalog is meant to be used.
• Tip: teach what you have learned. A short talk to your team about three patterns you found in your own codebase is worth more than rereading three chapters: explaining is the final proof of understanding.

Go through the "you know X if you can Y" table and, for each row, write down a real piece of evidence ("I proved it when...") or a "not yet". From the "not yets", rank your top three priorities and assign each one to a stretch of your 90-day plan.

Write half a page addressed to the person you were before lesson 01-01: which three things would you tell them about design patterns to spare them the most expensive misunderstandings? Don't repeat the core ideas verbatim; phrase them in your own words with your own examples.

Adapt the 90-day path to your reality: your available hours, your level according to exercise 1, and your professional goals. Write it into your calendar with concrete dates, and decide now the answer to the uncomfortable question: what will you do the week you fall short?

Exercise 1 (indicative): valid evidence is concrete and verifiable: "I can tell an Adapter from a Decorator: I proved it in the module 3 comparison, and yesterday I spotted a Decorator in BufferedReader". A typical "not yet" is the ADR — few people have ever written one — which is why the path places it in days 61-90, once you have PideYa design decisions of your own to document.

Exercise 2 (indicative): the most lucid letters tend to revolve around three warnings: "patterns are not recipes to apply but problems to recognize", "don't reach for the pattern on day one: wait for the second or third real case", and "learn the names even if they feel like pedantry — the day you say 'this calls for a Facade' in a meeting and everyone nods, you'll understand what all of this was for". If your letter contains warnings like these with your own examples, you have internalized the course.

Exercise 3 (indicative): a good personal plan is smaller than the proposed one, not bigger: if you only have 3 hours a week, maybe PideYa reaches stage 3 rather than 4, and the open source contribution moves to the next cycle. The mature answer to the uncomfortable question is not "I won't fail" but something like: "I pick it back up the following Monday where I left off, and if I miss three weeks in a row, I cut the plan in half instead of abandoning it".

This is the end of the Software Design Patterns course. It began with a definition — a named solution to a recurring problem in a context — and that definition kept growing until it covered a restaurant's menu, an admin panel's undo, an order's lifecycle, a hexagonal architecture, and a distributed saga. PideYa was the mirror: every pattern stopped being a diagram the moment it had an order, a courier, or a payment behind it.

You take three things with you. A catalog: the twenty-three GoF patterns and their modern heirs, with their intents and their costs. Judgment: choose for the problem, wait until it hurts, always weigh the trade-off. And a vocabulary: the ability to say "Adapter", "Strategy", or "Circuit Breaker" and be understood by any team in the world. The catalog is consulted, the judgment is trained, and the vocabulary is conversed — which is why all three improve with the years instead of expiring.

The rest is practice: your real PideYa waiting for its first commit, the first book on your path, your local community, your 90 days. The patterns that don't exist yet you will learn in minutes, because you already know the intents.

Thank you for making it to the end. It has been a pleasure designing with you. Now go write code worth reading.