Derive the architecture from the constraints, and defend it in the review.
What an architectural decision actually is, and the framework for making one.
Getting the information the decision depends on, out of people who did not know you needed it.
Nine candidates, each with the case for it, the case against it, and the case it is wrong for.
When and why to reach for a pattern — and the far more common answer, which is not yet.
Choosing databases, queues and infrastructure from the workload rather than from the feature list.
Turning drivers into a scored comparison you can put in front of a room.
Real briefs from real sectors, worked end to end.
Why the right decision has a shelf life, and how to plan for its expiry.
What a decision actually costs once someone has to run it.
The tool, how it decides, and how to build one yourself.
Why famous decisions were right for the company that made them, and wrong for you.
Write the document. Defend it.
Most engineers pick an architecture the way they pick a restaurant — by what is popular, what a big company was seen using, or what they enjoyed last time. The result is systems that are more complex than the budget, the team or the deadline can carry. This playbook replaces that with a method: extract the drivers, compare candidates on real trade-offs, score them against the constraints you actually have, and write the decision down in a form somebody else can argue with. You finish it able to produce an Architecture Decision Document and defend it in a design review.
Pounds are for students paying from inside Egypt. If you are paying from outside Egypt, the dollar price applies.
A practical playbook for building the skill of making architectural decisions — from reading requirements and extracting the architecture drivers, through comparing options, costing them and testing the decision, to writing the architecture decision down and defending it.
It does contain lessons, but the goal is not to teach you one more architecture. You learn the concepts and the patterns, then apply them to real decisions using the Decision Matrix, the Cost Simulator, the Architecture Simulator and design reviews.
Mainly mid-level and senior .NET developers who already know their way around .NET and architecture, and want to get better at making architectural decisions and defending them.
If you already know the architectures, that is exactly the part this is aimed at. The goal is not to tell you what to pick — it is to make you examine why you picked it, which trade-offs you accepted, and what it would cost to find out the decision was wrong.
You don't need to be an expert in them, but a decent grounding in software architecture makes the whole thing far more useful — especially the parts that turn on comparing architecture options.
No. There is no single best architecture for every project. You make the choice; the playbook and the simulators help you understand the consequences and the trade-offs that come with it.
You pick an architecture for a given project, and the simulator analyses your decision across several dimensions: architecture fit, cost, complexity, team fit, scalability, risk, ROI, rollback cost and future evolution.
Yes. You can run more than one architecture against the same project context and compare the results and the trade-offs, instead of going on impressions or personal preference.
The part that makes you think about what an architecture decision costs, not just whether you can build it. It looks at development, infrastructure, operations, maintenance, team, complexity and future change.
Architecture is not only a technical decision. The simulator helps you ask whether the value you get from a decision justifies the cost, the complexity and the risk it adds to the project.
Knowing an architecture can be changed is not enough. What matters is knowing what changing it will cost you if, a year in, the assumptions you built the decision on no longer hold.
No. The decision is yours. The simulator is built to challenge it and surface its strengths, its weaknesses and its trade-offs — not to replace your engineering judgement.
Yes. This is not a reading exercise. You move from the concepts into project discovery, the decision matrix, pattern decisions, technology decisions and decision workshops, then into the simulators, defending your decisions as you go.
Yes. You learn how to turn a decision into a documented one — something that can be explained, reviewed and defended in a design review.
The playbook is aimed at .NET developers, but the skill of architectural decision-making outlives any one framework or language, and applies just as well to other systems and stacks.
They are not the main audience. The material is built for someone who has reached the point of being expected to understand the trade-offs and take part in architectural decisions, which is why mid-level and senior engineers are the target.
Yes. There is a free version, so you can try the content and see how the playbook works before deciding whether to subscribe.
The free version exists so you can try the playbook. Subscribing opens the paid content and features of the full version, including the advanced parts and the complete run through the method and the tools, depending on your plan.
Yes. Try the free version first, and if the playbook suits you, subscribe for access to the paid content and features.
No. Once you have tried the free version and then subscribed to the paid one, the payment is non-refundable. So try the free version first and make sure the content fits what you need before you subscribe.
Because you get immediate digital access to the paid content and features, and you can preview and try the free version beforehand. That makes subscribing a final decision once the payment goes through.
No. The playbook is built as a complete experience. You can start with the content, the exercises and the simulators included in your access, without buying another course.
Both, but the point of it is application. You learn the concepts, then use them to analyse projects, compare options, estimate cost, test decisions and prepare an architecture decision.
Move from "I know Clean Architecture and microservices" to "I can choose an architecture based on context, explain the trade-offs, estimate what the decision costs, name its risks, and know when it should be revisited."
YouTube can teach you what an architecture is. This trains you on when to choose it, why you would choose it, what you pay for that choice, and how to defend it.
No. It is built as a journey you work through gradually, moving from the lessons into application, simulations and decision exercises.
That is part of the point. The simulator is not the final word. If your reasoning differs, you should be able to defend it — the aim is to train you in defending architectural decisions, not in obeying a tool's output.
The simulator works from project context, architecture drivers and trade-offs. The goal is not a magic number for your project, but a way to analyse the decision against assumptions you have stated clearly.
Decision-making. You should not leave having memorised more architecture options — you should leave better at answering one question: why this architecture, for this project, at this time, and what are you willing to pay for it?