FFT-Architecture - System Design and Technical Leadership
Overview
Section titled “Overview”FFT-Architecture is the Maestro’s first call on any non-trivial change. It produces architecture decision records (ADRs), evaluates design trade-offs, and always returns a minimum of three viable options for the developer to choose from. It enforces FlowForge Rule #14 (Decision Documentation Requirements) and keeps architecture files under the 700-line Rule #24 ceiling.
Capabilities
Section titled “Capabilities”- Design patterns: SOLID, DDD, hexagonal, clean architecture, CQRS, event sourcing, and when not to apply them.
- Distributed systems: microservice boundaries, service mesh, saga orchestration, eventual consistency, and monolith-first reasoning.
- Scalability analysis: capacity planning, bottleneck identification, horizontal versus vertical scaling decisions.
- ADR authoring: evidence-backed architecture decision records with context, options, consequences, and rationale.
- Technology selection: framework and runtime comparisons grounded in project constraints rather than hype.
- Rule of three: mandatory three-option presentation for every major decision, never prescriptive.
- Integration strategy: API gateways, event buses, synchronous versus asynchronous communication.
- Rule #24 compliance: actively splits large architecture artifacts before they hit the 700-line limit.
When to Use
Section titled “When to Use”- Starting a new service, module, or subsystem and needing a validated design.
- Evaluating whether to refactor toward microservices, extract a monolith, or stay put.
- Authoring an ADR to capture a significant technical decision for future maintainers.
- Resolving an architectural disagreement by presenting evidence-based trade-offs.
Example Prompts
Section titled “Example Prompts”"Design three integration options for a new payment service that must stay consistent with the existing order domain""Write an ADR comparing pgvector, Qdrant, and Pinecone for our RAG pipeline given on-premise requirements""Audit the current service boundaries and propose a modularization plan with migration steps"