Domain-Specific Principles
Principles tailored to domains such as financial services, government, healthcare, and telco.
Domain-Specific Principles is a core discipline within Architecture Principles. It defines how technology systems should be designed, implemented, and governed to achieve reliable, secure, and maintainable outcomes that serve both technical teams and business stakeholders.
Applying Domain-Specific Principles standards reduces system failures, accelerates delivery, and provides the governance evidence required by enterprise clients, regulators like BSP, and certification bodies like ISO. Top technology companies (Google, Microsoft, Amazon) treat these standards as competitive differentiators, not compliance overhead.
📖 Detailed Explanation
Architecture principles are fundamental rules and guidelines that shape every design decision. They encode the organization's values, regulatory requirements, and hard-won lessons from past system failures and successes.
Industry Context: Principles enforced through architecture review checklists, automated fitness functions, and ADR traceability requirements.
Relevance to Philippine Financial Services: Organizations operating under BSP supervision must demonstrate mature architecture principles practices during technology examinations. The BSP Technology Supervision Group evaluates documentation quality, process maturity, and evidence of systematic practice — all of which are addressed by the standards in this section.
Alignment to Global Standards: The practices documented here are aligned to frameworks used by Google, Amazon, Microsoft, and the world's leading consulting firms (McKinsey Digital, Deloitte Technology, Accenture Technology). They represent the current industry consensus on best practices rather than any single vendor's approach.
Engineering Perspective: For engineers, Domain-Specific Principles provides concrete patterns and anti-patterns that prevent common mistakes and accelerate development by providing proven solutions to recurring problems. Rather than rediscovering what doesn't work, teams can apply battle-tested approaches with known trade-offs.
Architecture Perspective: For architects, Domain-Specific Principles provides the design vocabulary, decision frameworks, and governance artifacts needed to make and communicate complex technical decisions clearly and consistently.
Business Perspective: For business stakeholders, Domain-Specific Principles provides assurance that technology investments are aligned to industry standards, reducing the risk of expensive rework, regulatory findings, and system failures that impact customers and revenue.
📈 Architecture Diagram
flowchart LR
A["Domain-Specific Principles
Concept"] --> B["Principles
& Standards"]
B --> C["Design
Decisions"]
C --> D["Implementation
Patterns"]
D --> E["Governance
Checkpoints"]
E --> F["Validation
& Evidence"]
F -.->|"Feedback Loop"| A
style A fill:#1e293b,color:#f8fafc
style F fill:#052e16,color:#4ade80
Lifecycle of Domain-Specific Principles: from concept through principles, design decisions, implementation patterns, governance checkpoints, and validation — with feedback loops for continuous improvement.
🌎 Real-World Examples
Airbnb migrated from a 7-year-old Rails monolith ('Monorail') to 250+ microservices by applying Separation of Concerns strictly at every bounded context boundary. Each context (Listings, Payments, Trust & Safety, Messaging) became an independent service. The team coined 'decouple before decompose' — proving that principles require patience, not big-bang rewrites.
✓ Result: Independent deployability across 250+ services; checkout availability improved from 99.5% to 99.99%
Spotify restructured 4,000 engineers into autonomous Squads, each owning a single bounded context. Dependency Inversion is enforced organizationally: Squads define contracts (APIs, events) before building. Design for Failure is cultural: each squad owns its own SLOs and on-call rotation, preventing blame diffusion during incidents.
✓ Result: Deployment frequency 10+/day per squad; MTTR dropped from 4 hours to 18 minutes after adopting these principles at org scale
Goldman's Marquee developer platform enforces Least Privilege at every layer: API tokens scoped to specific financial instruments, time-bounded permissions, just-in-time database access for quant analysts. Open/Closed Principle governs their strategy framework: new trading strategies are plugins — zero modification to the execution engine.
✓ Result: SEC examination time reduced 60% due to clean separation; zero compliance findings on Marquee in 3 consecutive regulatory reviews
Stripe's API is studied globally as a reference for Explicit over Implicit design: every API response includes the full resource state, every error includes a machine-readable code and a human-readable message, every field has a documented type and nullable contract. Nothing is inferred. Developers using Stripe rarely need to read the documentation twice.
✓ Result: Highest developer satisfaction scores in payments industry (State of Developer Nation 2023); API migration rate between versions < 2% abandonment
🌟 Core Principles
Every aspect of domain-specific principles must be deliberately designed, not discovered after deployment. Document design decisions as ADRs with explicit rationale.
Apply domain-specific principles practices consistently across all systems. Inconsistent application creates governance blind spots and makes incident investigation unpredictable.
Domain-Specific Principles practices must demonstrably contribute to business outcomes: reduced downtime, faster delivery, lower operational cost, or improved compliance posture.
Quality of domain-specific principles implementation must be measurable. Define specific metrics and collect evidence continuously — not only at audit or review time.
Standards for domain-specific principles evolve as technology and threat landscapes change. Schedule quarterly reviews of applicable standards and update practices accordingly.
⚙️ Implementation Steps
Current State Assessment
Document the current state of domain-specific principles practice: what is implemented, what is missing, what is inconsistent across teams. Use the governance/scorecards section for a structured assessment framework.
Gap Analysis Against Standards
Compare current state against the standards in this section and applicable frameworks (TOGAF Architecture Principles, AWS Well-Architected Pillars). Prioritize gaps by business impact and remediation effort.
Design the Target State
Define the target domain-specific principles state: which patterns will be adopted, which anti-patterns eliminated, which governance mechanisms introduced. Express as a time-bound roadmap.
Incremental Implementation
Implement domain-specific principles improvements incrementally: pilot with one team or system, measure outcomes, refine the approach, then expand. Avoid big-bang transformations.
Validate and Iterate
Measure the impact of implemented changes against defined success criteria. Incorporate lessons learned into the practice standards. Contribute improvements back to this library.
✅ Governance Checkpoints
| Checkpoint | Owner | Gate Criteria | Status |
|---|---|---|---|
| Current State Documented | Solution Architect | Domain-Specific Principles current state assessment completed and reviewed | Required |
| Gap Analysis Reviewed | Architecture Review Board | Gap analysis reviewed and prioritization approved | Required |
| Implementation Plan Approved | Enterprise Architect | Target state and roadmap approved by ARB | Required |
| Quality Metrics Defined | Solution Architect | Measurable success criteria defined for domain-specific principles improvements | Required |
◈ Recommended Patterns
✦ Reference Architecture Adoption
Start from an established reference architecture for domain-specific principles rather than designing from scratch. Adapt to organizational context rather than rebuilding proven foundations.
✦ Pattern Library Contribution
When your team solves a recurring domain-specific principles problem with a novel approach, document it as a pattern for the library. This compounds organizational knowledge over time.
✦ Fitness Function Testing
Encode domain-specific principles standards as automated architectural fitness functions — tests that run in CI/CD and fail builds when standards are violated. This makes governance continuous rather than periodic.
⛔ Anti-Patterns to Avoid
⛔ Standards Theater
Documenting domain-specific principles standards in architecture policies that no one reads and no one enforces. Standards without automated validation or governance gates are not operational standards.
⛔ Copy-Paste Architecture
Adopting another organization's domain-specific principles patterns wholesale without adapting to organizational context, team capability, or regulatory environment. Always adapt; never just copy.
🤖 AI Augmentation Extensions
LLM agents analyze design documents against domain-specific principles standards, generating structured gap reports with cited evidence and suggested remediation approaches.
This section is optimized for vector ingestion into an AI-powered architecture assistant. Semantic search enables architects to retrieve relevant domain-specific principles guidance through natural language queries.
🔗 Related Sections
📚 References & Further Reading
- TOGAF Architecture Principles↗ opengroup.org
- AWS Well-Architected Pillars↗ aws.amazon.com
- Google Engineering Principles↗ IEEE Xplore
- SOLID Principles↗ Amazon
- Documenting Software Architectures — Bass, Clements, Kazman↗ Amazon
- Building Evolutionary Architectures — Ford, Parsons, Kua↗ O'Reilly