Skip to content
GitHubLinkedIn

Architecture

Architecture is how LEF explains and shapes systems: intent, responsibilities, boundaries, and trade-offs.

A software system is made up of one or more containers (applications and data stores), each of which contains one or more components, which in turn are implemented by one or more code elements (classes, interfaces, objects, functions, etc). And people (actors, roles, personas, named individuals, etc) use the software systems that we build. See: C4 model.

In LEF docs:

  • A software system is typically an environment.
  • A lane in the DTAP flow is an occurrence of that system; the construct is stable across lanes.
  • Shared infra enablers (VPN/DNS/proxies/storage) are supporting systems, not “the system itself”.

We use an aspect model to describe systems as operational realities: not just “what runs”, but also how it is built, released, secured, and operated.

Each aspect is described through three dimensions: organization, process, and technique.

Explore: Aspects.

Terms: lane · DTAP · aspect model

ViewPurposeLEF docs entry point
System contextBig picture: system boundary, people, and external dependencies.System archetypes
Container modelMajor runtime building blocks (apps + data stores).System archetypes
Container archetypesThe canonical container types inside systems.Container archetypes
Infra enablersShared infra capabilities used by many systems.Infra enablers
Deployment (lanes)Where instances live and how shared enablers fit per lane.Delivery aspect
  • Architecture: explanation + maps + rationale (no inventories, no runbooks).
  • Reference: canonical facts (domains, servers, databases, environment definitions).
  • Run & Support: procedures, troubleshooting, and operational checklists.