This section contains Architecture Decision Records (ADRs) documenting significant architectural decisions made during the development of the Codexis system.
What is an ADR?
An Architecture Decision Record is a document that captures an important architectural decision made along with its context and consequences.
Why Use ADRs?
ADRs help us:
- Document the reasoning behind architectural choices
- Communicate decisions to the team
- Provide historical context for future team members
- Track changes to decisions over time
ADR Structure
Each ADR follows this structure:
- Title: A descriptive title that includes an ID number
- Status: Proposed, Accepted, Rejected, Deprecated, or Superseded
- Context: The issue or background that led to this decision
- Decision: The chosen approach and reasoning
- Consequences: The results of applying this decision, both positive and negative
- References: Related documents or decisions
List of ADRs
Below is the list of all architectural decisions:
| ID | Title | Status |
|---|---|---|
| 0001 | Record Architecture Decisions | Accepted |
| 0002 | Choose Ruby for Build Tooling | Deprecated |
| 0003 | Select Book Format and Conversion Workflow | Accepted |
| 0004 | Define Testing Strategy | Accepted |
| 0005 | Establish Project Structure | Accepted |
| 0006 | Standardize Error Handling and Logging | Accepted |
| 0007 | Define Dependency Management Strategy | Accepted |
| 0008 | Design Setup Tools Architecture | Accepted |
| 0009 | Implement Validation Strategy | Accepted |
| 0010 | Establish Blank Template Structure | Accepted |
| 0011 | Domain-Driven Design | Accepted |
| 0012 | Test-Driven Design | Accepted |
| 0013 | Behavior-Driven Design | Accepted |
| 0014 | Skim PDF Viewer | Accepted |
| 0015 | Extreme Programming | Accepted |
| 0016 | Centralized Path Configuration | Accepted |
| 0017 | Concurrency Patterns for Format Generation | Accepted |
| 0018 | Environment-Specific Configuration | Accepted |
| 0019 | Error Recovery Mechanisms | Accepted |
| 0020 | Git Town Workflow | Accepted |
| 0021 | Elixir/OTP Supervision Strategy | Accepted |
| 0022 | Elixir Module Structure | Accepted |
| 0023 | Command Execution Pattern | Accepted |
| 0029 | Elixir Implementation | Accepted |
| 0030 | Elixir CLI Tools Architecture | Accepted |
| 0031 | LaTeX Requirements: Fontspec, LuaLaTeX, and MathJax | Accepted |
| 0032 | Ollama Pool On Demand | Accepted |
| 0033 | Czur Scanner Integration Strategy | Accepted |
| 0034 | Unified Build System | Accepted |
| 0035 | Use Briefly for Temporary Files and Directories in Tests | Accepted |
| 0036 | BuildConfig Struct for Unified Build Configuration | Accepted |
| 0037 | Standardize Test Book Fixture for All Tests | Accepted |
Elixir Migration ADRs
The following ADRs are particularly relevant to the Elixir migration effort:
- ADR-0011: Domain-Driven Design
- ADR-0021: Elixir/OTP Supervision Strategy
- ADR-0022: Elixir Module Structure
- ADR-0023: Command Execution Pattern
- ADR-0017: Concurrency Patterns for Format Generation
- ADR-0019: Error Recovery Mechanisms
- ADR-0029: Elixir Implementation
- ADR-0030: Elixir CLI Tools Architecture
Document Processing ADRs
The following ADRs are particularly relevant to document processing and rendering:
- ADR-0003: Select Book Format and Conversion Workflow
- ADR-0025: External Tool Integration
- ADR-0031: LaTeX Requirements: Fontspec, LuaLaTeX, and MathJax
Legacy Ruby Implementation ADRs
The following ADRs are particularly relevant to the original Ruby implementation (now deprecated):