One-Line Summary: Architecture Decision Records (ADR) and Domain-Driven Design (DDD) are the two most-cited "discipline" methodologies in software engineering; ruflo packages each as a plugin (ruflo-adr, ruflo-ddd) so the discipline becomes a slash command rather than a team practice.
Prerequisites: Methodology as plugin (SPARC), plugin and marketplace systems
What Are ADR and DDD?
ADR (Architecture Decision Record) is a short document recording a single architectural decision: the context, the options considered, the choice, and the consequences. The discipline is write one whenever you make a non-trivial architectural decision so future maintainers (and your future self) can understand why the system looks the way it does. Famous practitioners: Michael Nygard's original ADR template (2011), the ADR community on adr.github.io.
DDD (Domain-Driven Design) is Eric Evans' (2003) approach to software design centered on understanding the business domain — its entities, value objects, aggregates, bounded contexts, ubiquitous language. The discipline shapes architecture around domain concepts rather than technical layers.
Both are widely respected and widely under-practiced for the same reason: they take effort upfront, and the payoff is long-term.
What "ADR as a Plugin" Looks Like
ruflo-adr (and similar plugins on other platforms) provides:
/adr-new <decision-title>: Slash command. Spawns a sub-agent that interviews the user about context, options, and trade-offs, then writes a properly-structured ADR file in the project./adr-review: Reviews recent commits for architectural decisions that should have been recorded but weren't, and suggests new ADRs.- A background worker that watches commits and surfaces missing ADRs proactively.
The user gets the discipline without the friction. They make a decision, type a slash command, review the agent-generated ADR, and commit.
What "DDD as a Plugin" Looks Like
ruflo-ddd is more ambitious because DDD is more pervasive:
/ddd-domain-model: Spawns sub-agents that interview the user (or read project docs) and produce a domain model — entities, value objects, aggregates, bounded contexts./ddd-bounded-context-map: Generates a map of bounded contexts and their relationships./ddd-language-check: A background worker that flags inconsistent terminology (the "ubiquitous language" violation) across code and documentation.
DDD-as-plugin tends to operate at a coarser grain than ADR — DDD is a project-shaping methodology, not a per-decision practice — but the pattern is the same: encode the discipline, lower the effort.
Why It Matters
The "methodology as plugin" pattern is one of the highest-leverage applications of agent harnesses. Methodologies are valuable but under-adopted because they are effortful. A plugin lowers the activation energy by 10× while preserving the discipline's structure. Teams that wouldn't sustain ADR or DDD as a manual practice will sustain them as a slash command.
The qualifier: a methodology degraded to filling out a template can lose the thinking the methodology was supposed to encourage. A good plugin biases toward asking real questions, not auto-filling boilerplate.
Key Technical Details
- Templates are the simplest form: An ADR plugin can be as little as a slash command that opens a templated file. More sophisticated plugins interview the user.
- Linkage to project history: Good ADR plugins reference the commits, files, and prior ADRs the new decision relates to.
- Tone and quality controls: ADRs that read like AI-generated boilerplate are worse than no ADR. Plugins should bias toward concrete, project-specific language.
- DDD plugins benefit from project-wide reading: Bounded contexts often map to directories or modules. The plugin reads the codebase to suggest mappings.
- Discipline-specific evals: Did the plugin produce a good ADR? "Good" is judged differently than "code that compiles." Eval rubrics need to be developed per methodology.
How Harnesses & Frameworks Implement This
| Harness / Framework | ADR / DDD support |
|---|---|
| Claude Code | DIY plugins |
| Claude Agent SDK | DIY |
| ruflo | First-class — ruflo-adr, ruflo-ddd |
| LangGraph / AutoGen / CrewAI | DIY applications |
| OpenAI Agents SDK | DIY |
| Codex CLI / Cursor | Limited |
Connections to Other Concepts
methodology-as-plugin-sparc.md— Adjacent example.plugin-and-marketplace-systems.md— The distribution mechanism.slash-commands.md— The user-facing trigger.agent-definitions-and-personas.md— Each methodology stage tends to be a persona.
Further Reading
- Michael Nygard, "Documenting Architecture Decisions" (2011) — Original ADR template.
- Eric Evans, Domain-Driven Design (2003) — Foundational DDD reference.
- ruvnet, ruflo-adr, ruflo-ddd sources.