Application Architecture
A new engineer joins DabbaGo and is asked to add "customers can skip tomorrow's tiffin". She opens the ordering app and finds skip logic in three places: the checkout screen, a nightly script and the kitchen report. Which one is real? Nobody drew the inside of the app, so every developer put things wherever was nearest. Application architecture exists to stop exactly this.
The rule
Give every rule one obvious home inside the app.
Application architecture is the architecture of one application: one codebase that is built and deployed as a unit. The application architect is responsible for:
- Modules and boundaries. What the main parts of the app are and what each owns. DabbaGo's ordering app might have
menu,cart,ordersandpayments. - Layers. How code is stacked, for example screens and API handlers on top, business rules in the middle, database access at the bottom.
- Dependencies. Which module may call which.
ordersmay askpaymentsto charge a card;paymentsshould not reach intoorders' tables. - Frameworks and conventions. The web framework, how errors are handled, how things are logged and tested, so every module looks familiar.
- The app's own quality needs. How fast checkout must be, what happens if the payment gateway is down.
A simple module map for the ordering app:
ordering-app/
menu/ today's dishes, prices, kitchens
cart/ what the customer is about to buy
orders/ placed orders, skips, cancellations, cut-off time
payments/ charging, refunds (talks to the gateway)"One obvious home" is the test. When the rule is "skips must happen before 10:30 pm the night before", there should be no debate: it is about an order's lifecycle, so it lives in orders, once.
The shortcut
Ask: "Could a new developer place this feature in the right box on day one?" If yes, the app's architecture is doing its job. If they would have to ask around, or pick a box by guesswork, the boundaries are unclear.
Name what the rule is about
It changes the state of a future order. That is order lifecycle.
The trap is putting logic where it is convenient rather than where it belongs: a rule in a screen because the screen was open, or in a script because the script ran nightly. Each copy drifts, and soon the app gives different answers depending on where you ask.
Drills
Answer fast — trust the rule.
What is the scope of application architecture?
DabbaGo's rule "an order cannot be cancelled after 11 am" should live in which module of the ordering app?
Which dependency direction is healthy in the ordering app?
A rule appears in the checkout screen, a nightly script and a report, each slightly different. What is the root problem?
Remember
- Application architecture shapes one app: modules, layers, dependencies, conventions and its own quality needs.
- Shortcut: could a new developer place this feature in the right box on day one?
- Trap: putting a rule where it is convenient instead of where it belongs.