We don’t lose velocity because we lack patterns; we lose it because we deploy too many, too early, and in the wrong places. “Pattern soup” (layers for the sake of layers, generic repositories, abstract factories everywhere) inflates accidental complexity, hides intent, and bloats maintenance budgets. Stories slow down, onboarding hurts, and every refactor feels like defusing a minefield. The real problem isn’t that we need more architecture; it’s that we need less, but sharper architecture guided by the domain.
Here is the lesson behind Mancuso’s advice: when Domain-Driven Design provides us with language and boundaries, and SOLID offers us object-level discipline, we usually have enough to craft code without polluting it with ceremonial scaffolding. Design from the problem space inward: model core concepts with a ubiquitous language; keep modules cohesive around business capabilities; prefer package-by-feature over package-by-layer; isolate side effects behind ports/adapters only where needed. Most of the time, clarity beats cleverness, and small, explicit seams beat heavyweight frameworks.
As a Staff Engineer, turn this into a lightweight operating system:
- 1. Frame the domain: run event-storming and publish a context map; align teams to bounded contexts.
- 2. Set guardrails: define coupling rules (who may depend on whom), enforce with architectural lint/import graphs, and bake SOLID smell checks into code review.
- 3. Adopt a pattern budget: every pattern needs an ADR with Problem → Forces → Decision → Consequences; if the forces vanish, the pattern goes.
- 4. Design for change: package by feature, keep interfaces small (ISP), invert dependencies at seams (DIP), and allow one change per reason (SRP).
- 5. Measure flow: track lead time, change-fail rate, churn in hot files; invest in refactoring where complexity and change co-locate.
Strategically, this restraint compounds. Teams ship smaller, safer slices because the code reads like the domain, not like a catalog. Maintenance costs decrease as intentions are clear and dependencies are minimal; refactors become more affordable because seams are tangible, not theoretical. Product wins speed through quality: fewer regressions, easier testing, clearer ownership.
Over quarters, you’ve quietly shifted from architecture theater to architecture that pays the bills, an organization that learns fast, evolves continuously, and controls complexity by design instead of ceremony.