Architectural Styles

The core is a small always-on engine that only knows how to load and talk to plug-ins. Plug-ins are separate, swappable pieces of code that add actual features, each following rules the core sets.

It's a design where data flows through a chain of independent processing steps called filters, connected by pipes. Each filter does one small job and hands its output to the next, like workers on an assembly line.

The client-server style splits an app into two roles: a client that asks for something (a request), and a server that has the data or logic and answers back (a response). The client initiates; the server waits and replies.

Calls only go downward: UI talks to business logic, which talks to data access. Data access never calls back up - that would tangle everything together, making each part impossible to change or test alone.

One app, one deployment, but cut into modules that hide their internals and only talk through defined entry points - unlike a folder-organized monolith where any code can still call any other code directly.

Inner circles (business rules) must never depend on outer circles (frameworks/DB). The use case defines an interface it needs; a database-specific class outside implements it. This keeps business logic free of database code.

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.

A producer creates and sends out an event (like 'something happened') without knowing who's listening. A consumer picks up events it cares about and reacts. Neither needs to know the other exists directly.

A microservice can be built, tested, and released on its own, without redeploying other services at the same time. This is the core feature that lets teams move fast without waiting on each other.

A coarse-grained SOA service bundles a whole business capability (like 'Order Management') behind one interface, instead of splitting into many tiny services, so fewer calls and less network chatter are needed.

JS mount loads the microfrontend's code into the same page so it shares the DOM and can talk to other parts easily. An iframe loads it as a separate mini-webpage inside a box, fully isolated but harder to communicate with.

A host is the app that loads pieces from other apps; a remote is the app that shares its pieces. Webpack lets the host fetch and run the remote's code straight from the browser, without both being built together.

Choose from the qualities the system must have (scale, availability, speed of change, cost) plus its constraints (team size, skills, deadline, budget, regulation). Do not choose by fashion, resume value, or what a famous company uses.

A hybrid architecture combines more than one architectural style in one system, for example a modular monolith plus serverless functions at the edge. Different parts of a system have different needs, so one style rarely fits everything.

An ADR is a short document recording one significant architecture decision: the context, the options considered, the decision, and its consequences. It matters because it preserves why something was chosen, so later teams can tell a deliberate trade-off from an accident.

A modular monolith is one deployable unit with internal module boundaries: simple, cheap, easy to test, with single-database transactions, but it scales and ships as a whole. Microservices deploy and scale independently and isolate failures, but add network calls, eventual consistency and operational cost.

Use a synchronous call when the caller needs an answer right now to continue its work. Use an asynchronous event when you are announcing that something happened and other services can react later, without the caller waiting.