10KB
FOCUS Architecture — Chapter-01: About the Author
- Source: /library/FOCUS Architecture/source-file.pdf
- PDF pages: 13–20
- Pages without text: none
About the Author In this chapter, you’ll: Recognize the cost of a project with too many layers Recognize the opposite cost: a project with no layers at all State this book’s thesis in a single sentence Have you ever opened a project and spent a week hunting for where a business rule lived? I have. This chapter tells the scars that led me to one conviction: building software shouldn’t be hard, and four pieces are enough. The F12 test I have a favorite test for measuring a project’s health. It’s fast and it doesn’t forgive. I open the IDE (Integrated Development Environment), rest the cursor on some call, and press F12. If I land straight on code that does something, the project passes. If I land on an interface that points to an abstraction that delegates to another abstraction, and ten jumps later I still haven’t found a line that produces an effect in the real world, the project fails. And I already know how deep the trouble runs. I learned this test the hard way. I consulted for a multinational insurance company, on a project that flew the DDD (Domain- Driven Design) flag and had read Eric Evans’s book as a catalog of mandatory layers. The problem wasn’t DDD, which was born to
bring code closer to the language of the business; it was the reading that turned every suggestion in it into law. In practice that was a stack of dozens of layers, where every implementation, however small, meant creating or changing several files. A new rule? Half a dozen files. The process was tedious and, worse, error-prone: the rule was spread across so much ceremony that nobody, not even whoever had written it, could see the whole thing at once. That project was traumatic. It wasn’t supposed to be complicated: customer records, policies, calculations, reports, a system like countless others, the kind any small, disciplined team would have shipped without drama. The complexity didn’t come from the business. It came from the architecture choice. Code should be simple, direct, and to the point, and in decades of my career I rarely saw that. This book exists to make “rarely” less rare. The price of too many layers I’ve been programming professionally since 1995, and I’ve watched that insurance company’s scene repeat in projects of every size: simple systems drowned in ceremony, boilerplate (the repeated ceremonial code you type the same way every time and that decides nothing), and verbosity, until productivity dies. Every layer is born from a promise: “this will give us flexibility.” The promise almost never delivers. What every layer delivers for certain is cost: one more file to create, one more contract to maintain, one more place where someone will paste a business rule by mistake. When the core of the system swells, the architecture turns into bureaucracy. And bureaucracy, in code, gets paid for with every change, every day, for the rest of the project’s life.
You’ve probably seen a project like this. Maybe you’re stuck in one right now. The classic sign: the task looked like an hour of work and ate three days, because the small change crossed seven files and broke tests that had nothing to do with it. Nobody designed it that way out of malice. Layer by layer, each decision seemed sensible. The cost only shows up later, added up. The price of too few layers I met the opposite pain much earlier, inside my own code, in a system I had written alone that ran real customers’ business. It was 1998, and the system was an ERP (Enterprise Resource Planning) built in Visual Basic 6. At first it was beautiful: no layers at all, the screen talked straight to the database, and every customer request turned into a feature the same day, sometimes with the customer still on the phone. Then the requests didn’t stop. Every new feature made the system more fragile; any change spawned bugs in spots nobody had touched in months, until maintenance became impossible. The 1998 ERP and the multinational insurer had opposite diagnoses and the same disease: the cost of change exploded. In one case, because the business rule was scattered across too many layers; in the other, because it was mixed in with screen and database, with no place to call its own. Keep that measure in mind. It’s the thread running through this book. Four pieces The answer wasn’t my invention, and it didn’t fall from the sky in a flash of epiphany. It came from digging: decades gathering techniques from books, blogs, and people better than me, each one tested and proven by millions of developers around the
world. FOCUS is what survived that filter. Nothing here is new. The filter ran for real on one of my own products: Meu Cronograma Capilar (“My Hair Care Schedule”), a hair-care routine app I built in 2017, in Xamarin, kept deliberately simple. I rewrote it in Ionic, and JavaScript couldn’t keep up with my audience’s weak, outdated phones. I rewrote it again in Flutter. I was still learning the technology, and I leaned on what I already knew from Vue.js and MobX. The app wasn’t born with the architecture in place. It got distilled version after version: I cut what didn’t earn its own cost and reinforced what held changes together. Today the app carries more than 10 million downloads, a 4.8 rating on the Play Store, more than 300,000 active users, and 99.5% crash-free sessions, with sporadic updates, and I know exactly where everything lives. I never have to guess. What survived the distillation were four pieces. I never had to question the two ends: a View shows things on screen and a Repository stores and fetches data; every system in the world has both. The middle was the only open question. Too much in the middle turns into the insurer’s bureaucracy. Too little turns into the 1998 ERP: repeated rules, an orchestrator calling another orchestrator, and changes that break ends nobody saw coming. The middle ground that survived every one of those versions was an Orchestrator that only translates events into state, and Use Cases that hold every business rule in functions you can test without booting a screen or a database.
Think of this diagram as the trailer for Part III. Each of these pieces gets its own chapters, with code and with the criticism it deserves. Why now I wrote Spec Driven Development (2026, https://books.kodel.com.br/en/books/sdd), where I argue that describing precisely what you want doesn’t compete with AI, it multiplies what you get from it; you do not need to have read that book to follow this one. This book exists to pull one loose thread, a sentence I repeated more often than I liked: doing SDD (Spec Driven Development) without structure is vibe coding with extra ceremony. A model synthesizes code fast, and that’s where structure decides the outcome: with nothing firm underneath, what comes out is the same old tangle, only quicker; GitClear’s AI Copilot Code Quality reports (2024-2026) already measure that damage, and the numbers wait for chapter 3. With the right
structure, the opposite happens: the model recovers the context that matters before synthesizing, the new code doesn’t break its neighbor, and whoever reads it later understands what was done. Who looks for the rule now In 1998, the only reader of my ERP was me. I’d open Visual Basic with last week’s work still fresh in my head, and the whole project fit in there. No living project has a single reader today. The code of one single day passes through the hands of whoever joined the team last month, whoever reviews the pull request late in the afternoon, and a language model handed the task with nothing but what was open in the editor. The model works in three movements: it recovers the context it can see, infers the intent from it, and synthesizes code that fits there. Getting the first movement wrong ruins the other two, and the first one depends entirely on how the project is organized. It’s the same dependency as the person who joined last month, only measured in seconds instead of weeks. Add the two up and you reach the arithmetic that changed. Implementing a rule got cheap: describing Rosie’s loyalty discount and getting the function back takes less time than opening the right file. Locating where that discount lives still costs what it always cost. When one side of the arithmetic collapses and the other doesn’t, finding becomes the expensive part, not implementing. Hence the thesis of this book, in the single sentence it fits into: architecture lowers the cost of change because it makes the intent of the system recoverable, navigable and predictable for
humans and for models. The four pieces from the previous section are the means. That sentence is the end, and the rest of the book is the tally of what each piece charges to deliver it. Rosie’s Coffee Shop Every architecture book trips on the same spot: each chapter invents a new domain, and you spend more energy understanding the example than the concept. Not here. This entire book uses a single domain: the ordering app for Rosie’s Coffee Shop, with a menu, tabs, inventory, payment, and a loyalty program. Rosie doesn’t exist; she’s a character in this book. I picked this domain on purpose, because a coffee shop is a business everyone understands and that leaves no room to overcomplicate: if the architecture looks heavy for Rosie’s Coffee Shop, it’s heavy for real. Quick reference Situation Fix Evaluating an unfamiliar project F12 test: count the jumps to the code A simple task touches half a dozen files Too many layers: cut A change breaks code nobody touched Too few layers: give the rule an address Choosing between two architectures Measure the cost of change for each
Looking for a business rule It lives in the Use Case; the View just renders Tip 1 Architecture is measured in cost of change, not number of layers. Next chapter: the day changing one line broke three screens, and what that accident teaches about where business rules should live.