Architecture
Clojure Architecture & Technical Consulting
System design grounded in data, boundaries and restraint — so the architecture still makes sense to the engineers who inherit it.
(def system
{:boundaries :explicit
:state :contained
:data :first-class})Highlights
Data first
Model the information before the modules. In Clojure, the data model is the architecture.
Boundaries that hold
Explicit seams between domains, services and side effects, so change stays local.
Decisions on paper
Every significant choice recorded with its trade-offs, alternatives and reversal cost.
Architecture as the cost of future change
Architecture is not a diagram; it is the set of decisions that determine how expensive your next twenty changes will be. Good architecture makes the common change cheap and the dangerous change obvious. Bad architecture inverts that, and teams feel it as slowing velocity long before anyone calls it an architecture problem.
In Clojure the leverage points are specific: where state lives, where side effects happen, how data flows and gets validated, and how much of the system can be exercised in a REPL without a running cluster.
- Domain and service boundary design
- State, lifecycle and dependency wiring
- Data modelling in Datomic, PostgreSQL or event stores
- Synchronous versus event-driven trade-offs
- Consistency, idempotency and failure semantics
- Testability and REPL-driven feedback loops
Principles that guide the work
Simplicity in Rich Hickey's sense — not easy, but unentangled. Prefer plain data over classes and protocols. Push side effects to the edges so the core is a pure transformation. Keep abstractions earned rather than anticipated. Make the system observable before making it clever.
These are not slogans; they are the criteria used to evaluate a design. When a proposal adds indirection, the question is always which specific future change it makes cheaper, and whether that change is actually likely.
- Immutable by default
- Data-oriented over abstraction-oriented
- Composition over frameworks
- Explicit boundaries, contained state
- Observable before optimized
Accessible to engineering leadership
Architecture work is only useful if the people funding it can evaluate it. Deliverables are written for CTOs and engineering managers as much as for engineers: what the system looks like today, what the options are, what each one costs, and what happens if you do nothing.
Recommendations are sequenced so that value arrives early. There is no six-month prerequisite phase before anything improves.
Frequently asked questions
- Is architecture work only for new systems?
- No. Most architecture engagements are about existing systems — reshaping boundaries, reducing coupling and making change cheaper without stopping delivery.
- Do you prescribe a particular Clojure stack?
- No. Component or Integrant, Datomic or PostgreSQL, Ring or something else — the right choice depends on the team, the operational reality and what already works.
- What do we get at the end?
- Written architecture documentation, decision records with trade-offs, and a sequenced plan your team can execute independently.
Planning the next stage of a Clojure system?
Whether you're maintaining an existing platform, extending your engineering team or planning the next stage of a Clojure system, start with a technical conversation.