Application Architecture

A port is an interface the core app defines. Driving ports are ways the outside world calls INTO the app (like an API). Driven ports are ways the app calls OUT to things it needs (like a database).

Model holds data and business rules, View shows it on screen, Controller takes user input and decides what happens next. Splitting them means you can change how something looks without touching how it works.

Onion Architecture puts the business rules in the middle of the app, like the core of an onion, and everything else (database, web framework, UI) sits in layers wrapped around it. The middle never needs to know about the outer layers.

Entities hold core business rules; Use Cases run application-specific workflows; Interface Adapters translate between the app and the outside world (controllers, presenters); Frameworks/Drivers are the actual web server, DB, UI. Data crosses rings as plain data structures, converted at each boundary.

The core only knows about interfaces it defines itself, never concrete tech classes. A separate wiring step (like a dependency-injection setup) plugs the real adapters in at startup, so the core's code never imports database or web code directly.

In MVP, the View is a dumb interface and the Presenter tells it exactly what to display, instead of the View pulling data from the Model itself like in MVC. This makes the app's logic testable without a real screen.

The inner code defines an interface saying what it needs (like 'save this order'); the outer database code writes a class that fulfills that interface. The inner code never imports database code directly — it just calls the interface, and something else plugs in the real database class at startup.

A domain service holds business rules that don't fit inside one entity, like 'does this transfer amount exceed the daily limit.' An application service coordinates a whole use case step by step, like 'validate, call the domain service, save, notify.' Domain services sit closer to the center; application services wrap around them.

You gain testability and the ability to swap frameworks/DBs later, but you pay in more files, more boilerplate, and slower ramp-up. For a small short-lived CRUD app that will never swap its DB or framework, skip the full structure.

The core holds the transfer rules (enough balance? valid accounts?). A driving port lets something like an API call 'do this transfer.' Driven ports let the core ask for things it needs, like reading and saving account balances, without knowing how those things are actually done.

The ViewModel exposes its state as observable values, like a stream or property that broadcasts changes, and the View watches those values and updates itself automatically. The ViewModel never has to know the View exists or call it directly.

The top-level folders should announce what the app DOES (its use cases/domain), like 'Shipping' or 'PatientIntake' - not what framework it's built with, like 'controllers/models/views.'

Because business logic only talks to interfaces, tests can swap in fake, in-memory versions of the database or payment gateway instead of the real ones, so tests run fast with no network or database needed, while still checking real business rules.

A controller converts an incoming request into a simple input object the use case understands; the use case returns a simple output object; a presenter turns that into a view model/JSON. Passing entities straight out would leak internal business objects (and their behavior) into the web layer.

It means more files and interfaces for simple stuff, and it only pays off if you actually need to swap technology or test business logic heavily. For a tiny app with one database and one UI that will never change, it's often just extra work with no real benefit.

For simple screens, MVP's explicit code is easy to follow and not much extra work. For complex screens with lots of changing state, MVVM's automatic updates save a ton of repetitive code, but you trade that for a debugging chain that's harder to trace step by step.

It adds extra files and steps (interfaces, mapping code) even for simple features, which slows down small or short-lived projects. If the app is a small CRUD tool or throwaway prototype with a stable, simple database, that extra structure often isn't worth the time it costs.

Business rules keep sneaking into the Controller/Presenter/ViewModel because that's the easiest place to add 'just one more check' while wiring a screen. The fix is a separate, UI-independent layer, like domain services, that owns the rules, with the middle layer just calling it.

All three put business rules in the middle and infrastructure on the outside, with dependencies pointing inward — they're basically siblings with different names for similar ideas. Onion Architecture is the one that talks about rings (domain, domain services, application services, infrastructure); the others use different vocabulary for similar ideas.

All three push business logic to the center and keep dependencies pointing inward. Clean Architecture specifically names four rings (Entities, Use Cases, Interface Adapters, Frameworks/Drivers) and pairs that with the Dependency Rule and 'screaming architecture' - a bit more prescriptive about layer count and naming than the other two.

At scale, teams often make too many tiny interfaces (a mess to navigate), write fakes that don't match real behavior, or build one giant port instead of several focused ones — each quietly brings back the same coupling and confusion the pattern was meant to prevent.