🏛️ Software Architecture Language

Senior engineers use phrases like "we're trading consistency for availability here" or "the latency cost is acceptable given the throughput gain" to make trade-off reasoning explicit. Common pairings include coupling vs. cohesion, flexibility vs. simplicity, and operational complexity vs. independent deployability — precision with this vocabulary signals architectural maturity.

Hexagonal architecture, also called Ports and Adapters, structures an application so that the core domain logic is isolated from external systems (databases, UIs, APIs) via defined interfaces called ports. Engineers describe it by saying "the domain has no dependencies on the infrastructure layer" or "we invert the dependency so the database adapter implements the repository port".

An ADR is a short document capturing the context, decision, and consequences of a significant architectural choice. The standard vocabulary includes "forces" (the constraints and concerns driving the decision), "alternatives considered", and "accepted trade-offs" — teams say a decision is "superseded" when a later ADR replaces it, preserving the historical reasoning.

Cohesion refers to how strongly related the responsibilities within a module are — high cohesion means a module does one thing well. Coupling refers to the degree of dependency between modules — low coupling means changes to one module are unlikely to require changes in another. Architects aim for "high cohesion, low coupling" as a guiding principle for modular design.

The strangler fig pattern is a strategy for incrementally replacing a legacy system by building new functionality alongside it and gradually routing traffic to the new implementation until the old system can be retired. Engineers say they are "strangling the monolith" when they extract bounded contexts one by one, using a facade or API gateway to proxy requests between old and new systems during the transition.

In a layered architecture, components are organised into horizontal tiers (presentation, business logic, data access) where each layer only calls the layer directly below it. In an event-driven architecture, components communicate asynchronously by producing and consuming events, which engineers describe as "decoupled via the event bus" — the key contrast is synchronous request/response vs. asynchronous fire-and-forget.

A bounded context is an explicit boundary within which a particular domain model applies and within which terms have consistent meanings. Engineers use it to resolve ambiguity when the same word means different things in different parts of a business — for example, "customer" in the billing context may have different attributes than "customer" in the shipping context.

Evolutionary architecture supports guided, incremental change across multiple architectural dimensions as the first principle. Engineers describe a system as having good evolutionary fitness when it can be changed quickly without accumulating excessive technical debt, often enforced through "fitness functions" — automated tests that verify architectural constraints such as dependency direction or performance thresholds.

A modular monolith organises code into well-defined modules with strict boundaries but deploys as a single unit, while microservices deploy each service independently. Engineers typically argue for a modular monolith first, saying "the operational overhead of microservices is only justified once you need independent scaling or team autonomy at scale" — the key trade-off is deployment flexibility against distributed systems complexity.

Conway's Law states that organisations design systems that mirror their own communication structure. Architects invoke it when arguing for team topology changes alongside architectural changes, using phrases like "our monolith reflects our monolithic team structure" or "we should align service boundaries with team boundaries to reduce coordination overhead".