Enterprise Edition v8
Architecture as Code.
A unified domain-specific language for modeling complex enterprises using
Dragon1, UML, C4, ArchiMate, and BPMN.
What is ArchDSL?
ArchDSL or ArchitectureDSL is a powerful Domain-Specific Language designed (04/15/2026) to treat enterprise architecture as a software engineering discipline. It eliminates static, out-of-date diagrams by allowing architects to code their models.
In a world of rapid digital transformation, traditional modeling tools are too slow and siloed. ArchDSL provides a single source of truth that translates human strategy into machine-readable blueprints across all industry-standard frameworks.
Why it's Necessary
Stops 'Architecture Drift' by ensuring documentation evolves with the code.
Strategic Benefits
Automated impact analysis and 40% faster blueprint generation.
Collaborative Governance
Allows Git-based versioning and peer reviews for architecture changes.
General Language Rules
The foundational grammar for defining architectural entities, scoping metadata, and mapping complex relationships.
Rules #1 & #2
Entity Definitions & Property Scoping
Entities are the primary building blocks. Every definition requires a unique ID, a Label, and a Framework Tag. Attributes (metadata) are distinguished from components using the hyphen prefix.
Declarative Initialization
@[framework]:[class] [id] "[Label]" { ... }
[id] "[Label]" @[framework]:[class] { ... }
Metadata Scoping
{
-[key] (=/:) [value] (,)
-attr (=/:) [key] [value]
}
Standard Syntax Template
class/type definition EntityID "EntityName" {
-type: "FrameworkType",
-scope = "Global | Local",
-attr name = "value"
}
@c4:person rider "Rider" {
-description "Requests rides via mobile app"
-attr tier = "Premium"
}
Rules #3 & #4
Relationships & Relational Logic
ArchDSL connects entities through directed flows or explicit relational objects. Rule #4 enables Nesting, allowing entities to exist within logical or physical boundaries.
1. Directed Flows Implicit
Quick mapping of dependencies or simple data movement.
source_id -> target_id "Description of action" relationship type
2. Relational Objects Explicit
Used when a relationship carries its own metadata (protocols, security, etc).
relationship ServiceLink {
from: trip_api,
to: matching_engine,
verb: "synchronous_call",
metadata: {
-protocol: "gRPC",
-security: "mTLS"
}
}
3. Nesting & Hierarchy Rule #4
Encapsulation of child components within a parent system boundary.
ride_service "Ride Service" @c4:system {
component trip_api "Trip Gateway" @c4:api {
...
}
component trip_db "Trip Store" @c4:database {
...
}
}
Dragon1 allows you to bridge the gap between business strategy and IT through principles and blueprints.
principle CloudFirst {
-statement = "All new services must be cloud-native",
-rationale = "Ensures elasticity and cost-efficiency",
-impact = "Zero physical hardware procurement for new apps"
}
blueprint RetailExpansion {
includes = [CloudFirst, MicroservicesOnly]
}
The open standard for EA modeling, covering business, application, and technology layers.
layer Business {
process OrderProcessing
}
layer Application {
component SAP_Instance
}
SAP_Instance realizes OrderProcessing
Precise structural and behavioral modeling for software-intensive systems.
class UserAccount {
id: UUID
email: String
func validateLogin(): Boolean
}
Admin extends UserAccount
workflow ClaimApproval {
startEvent RequestReceived
task AssessRisk
gateway Approve?
endEvent Finalized
}
context BankingSystem {
person Customer
system EmailService
}
Customer uses BankingSystem
Phase 1: Strategic Alignment
1. Dragon1 Architecture Principles
Defining the Way of Thinking for GlobalBank's 2026 digital roadmap.
real_time_sync "Real-Time Data Availability" @dragon1:principle {
-statement "All financial transactions must be reflected in user balances within < 200ms."
-rationale "Customer trust depends on instant feedback for mobile-first users."
}
customer_growth "Mobile User Dominance" @dragon1:goal
real_time_sync supports customer_growth
Phase 2: Business Process
2. BPMN Loan Approval Workflow
Modeling the orchestration of a modern loan request to replace manual cycles.
loan_request @bpmn:startevent "Mobile App Request"
check_credit @bpmn:servicetask "AI Risk Evaluation" {
-implementation "RiskSentry-v2-Model"
}
approval_gate @bpmn:exclusivegateway "Score > 750?"
loan_request -> check_credit -> approval_gate
approval_gate -> issue_funds "Yes"
Phase 3: Software Architecture
3. C4 Container Mapping
Drilling down into the technical stack of the Lending Sub-system.
lending_system @c4:softwaresystem {
api_gateway @c4:container {
-technology "GraphQL / Apollo"
-description "Single entry point for iOS/Android"
}
risk_engine @c4:container {
-technology "Python / FastAPI"
}
api_gateway -> risk_engine "Invokes risk assessment"
}
Phase 4: Global Traceability
4. ArchiMate Transformation Map
Linking technical components back to business services and strategic goals.
loan_biz_service "Instant Lending" @archimate:businessservice
risk_app_comp "Risk Microservice" @archimate:applicationcomponent
risk_app_comp realizes loan_biz_service
loan_biz_service achieves real_time_sync
Ready to model your transformation?
ArchDSL allows you to keep your architecture source-of-truth in Git, versioned alongside your code.