Domfolio Knowledge Library

Decisions and ADRs

Locked architectural decisions and how to evolve them responsibly.

Audience
Engineering leadership and contributors
Source
docs/adr/README.md
Last updated
March 3, 2026

Current Locked Decisions

  • Start API rollout now using a strangler migration approach.
  • Keep API private-first for first-party clients in early phases.
  • Use shared database tenancy with strict workspace scoping.
  • Use hybrid auth: web sessions + token auth, OAuth2 later for third parties.
  • Target Stripe and QuickBooks first for integrations.

How ADRs Should Be Used

  1. Create a new ADR before changing a locked architecture decision.
  2. Document context, decision, alternatives, and migration impact.
  3. Link the ADR to affected code paths and tests.
  4. Mark replaced ADRs as superseded instead of deleting history.

Governance Notes

ADRs should remain concise, date-stamped, and implementation-aware. They are the authoritative source for why architecture and policy choices were made.

Source File

Decision history and ADR process live in docs/adr/README.md.

Product Overview

What Domfolio is, who it serves, and how major modules fit together.

Product Roadmap

Planned capabilities and phased expansion priorities for the platform.

Architecture

Current Django + HTMX architecture, request flow, and migration direction.

API v1

Versioned private API contract, auth model, envelopes, and endpoint map.

Domain Model and Roles

Workspace-scoped entities, role capabilities, and authorization boundaries.

Integrations

Stripe, QuickBooks, and Thumbtack-compatible connector patterns.

Security and Compliance

Authentication controls, audit trails, and SOC2-ready implementation posture.

Quality and Reliability

How release safety, reliability checks, and developer test depth fit together.

Operations and Runbooks

Operational procedures for incident response, sync failures, and release safety.

Decisions and ADRs

Locked architectural decisions and how to evolve them responsibly.