Documentation
Philosophy.md
Dynaplex Philosophy
The Unified Paradigm
Dynaplex is not a framework. It is not a set of architectural patterns. It is not a collection of developer tools. Dynaplex is all of these things, unified into a single coherent paradigm for building software.
The fundamental insight of Dynaplex is that the traditional separation between "how we build software" and "what we build" is artificial and counterproductive. The development environment, the coordination mechanisms, the architectural patterns, and the runtime infrastructure are not separate concerns—they are facets of a single unified approach to software creation.
Core Principles
1. Architecture and Tooling Are Inseparable
In traditional software development, architecture is designed first, then tools are built or adopted to support that architecture. This creates a constant tension:
- Architects design patterns that tools struggle to enforce
- Tooling limitations constrain architectural possibilities
- Developers work around both, creating divergence
Dynaplex rejects this separation. The architectural patterns (component structure, service boundaries, type-safe communication) and the tooling (agent coordination, CLI tools, memory systems, MCP servers) evolved together. They inform and strengthen each other.
When we say "Dynaplex architecture," we mean the component structure, the Aspire orchestration, the type-safe contracts. When we say "Dynaplex tooling," we mean the agent infrastructure, the CLI, the development utilities. But these are not separate things—they are complementary aspects of a unified whole.
2. The Development Environment Is Product Philosophy
Most organizations treat the development environment as a necessary evil—something to be tolerated while building the "real" product. Dynaplex inverts this:
The way we build software is as much a part of our product as what we build.
Our investment in agent coordination, development tooling, and workflow automation is not overhead. It is a direct expression of our values:
- Quality over speed: Architectural boundaries are enforced, not suggested
- Collaboration over heroics: Agent coordination ensures parallel work without conflicts
- Automation over repetition: Tools handle the mechanical; humans handle the creative
- Transparency over mystery: Every pattern has documentation; every decision has an ADR
When customers work with our software, they experience the benefits of this approach even if they never see the development environment.
3. Agents Are Part of the Development Process
Dynaplex embraces AI agents not as external tools but as integral participants in the development workflow. This is not about "AI-assisted development"—it is about a development paradigm where agents and humans collaborate as peers.
The agent infrastructure (Agent Teams for coordination, Linear for issue tracking, file-based identity management) was not added as an afterthought. It was designed from the beginning as a core part of how Dynaplex-based projects operate.
This has profound implications:
- Parallel development is the norm: Multiple agents working simultaneously on different concerns
- Coordination is explicit: No implicit assumptions about who is working on what
- Memory persists across sessions: The memory system ensures context survives compaction
- Work is traceable: Every action, every decision, every change is documented
4. Portable by Design
Dynaplex is not tied to any specific repository or project. The acsis-core repository is an example of a repository using Dynaplex, not the definition of Dynaplex itself.
The infrastructure that enables Dynaplex—the agent coordination tools, the CLI utilities, the identity system—is designed to be extractable and reusable:
- Cortex: Identity management and web UI, portable to any project
- Component patterns: Applicable wherever .NET Aspire runs
- Architectural principles: Language and framework agnostic at their core
A new project adopting Dynaplex does not clone acsis-core—it adopts the patterns and installs the tooling.
The Paradigm Shift
Traditional software development is organized around code. Projects are collections of source files that produce artifacts. Development is the act of modifying those files.
Dynaplex is organized around capabilities. A Dynaplex project is a collection of components that provide capabilities. Development is the act of composing, extending, and orchestrating those capabilities.
This shift has consequences:
| Traditional | Dynaplex |
|---|---|
| Projects have source files | Components have contracts |
| Developers edit code | Agents and developers compose capabilities |
| Build systems produce artifacts | Aspire orchestrates services |
| Integration happens at deployment | Type-safe communication happens at build |
| Documentation describes code | Contracts are self-documenting |
Why This Matters
The software industry has spent decades separating concerns that should be unified:
- Architecture vs. implementation
- Development vs. operations
- Human developers vs. automation
- Tooling vs. product
Each separation creates friction. Each boundary becomes a point of failure. Each handoff loses information.
Dynaplex unifies these concerns not by eliminating distinctions but by ensuring they work together as parts of a coherent whole. The architecture informs the tooling. The tooling enables the architecture. The development process embodies the product philosophy. The agents extend human capabilities.
This is not just a better way to build software. It is a different way of thinking about what software development is.
Living the Philosophy
Adopting Dynaplex is not about installing tools or following patterns. It is about embracing a philosophy:
- Invest in the development environment: It is not overhead; it is product
- Design architecture and tooling together: They are one concern
- Embrace agents as peers: They extend what is possible
- Enforce boundaries: Suggestions become violations; conventions become contracts
- Document decisions: Every choice has context; every context deserves an ADR
The goal of Dynaplex is to serve as the core for the best software in the world. That goal is only achievable if we are willing to fundamentally rethink how software is built.
Dynaplex is a paradigm, not a product. It is a way of thinking, not just a way of building.