ALD’s Natural Place in a Business-Driven Development Framework

Business-Driven Development clarifies what the business needs and why. Architect-Led Development (ALD) turns that intent into enforceable contracts—role-based interfaces, DTOs, and tests—so implementation can be safely delegated.

See the model View the mappings

ALD is the execution discipline that connects business intent to working software—without losing rigor.

Positioning

ALD is the bridge between business intent and implementation: it defines where decisions live and how behavior is proven, while AI or teams build implementations under those constraints.

Business intent Decision boundaries Contracts Tests as agreement Delegated execution Lower regression risk

Why ALD matters in BDD

The common gap

Many business-driven approaches excel at identifying goals, capabilities, value streams, and policies—but often stop short of making that intent testable and enforceable in code.

  • Capabilities are defined, but decision boundaries are fuzzy
  • Policies exist, but drift into “services” and ad-hoc logic
  • Acceptance criteria live in tickets, not in executable contracts
  • Change becomes risky because behavior is implicit

ALD fills the gap

ALD converts business intent into a stable, evolvable contract surface: role-based interfaces + DTOs + contract tests.

  • Policies become replaceable implementations (OCP at the business level)
  • Behavior is proven via tests that act as an agreement
  • AI can generate code safely because ambiguity is constrained
  • Change is localized to decision points, reducing regression risk
Key takeaway: BDD decides what should happen. ALD decides where decisions live and how they’re enforced.

The 3-strata model

Think in vertical strata (intent → contracts → execution), not horizontal tech layers.

Business Intent & Governance

Strategy, policies, capabilities, value streams, regulatory constraints, risk posture.

Capabilities Policies OKRs Compliance
Architect-Led Development (ALD)

Role-based interfaces and DTOs express decisions; contract tests prove behavior. This is the “control plane.”

Roles Contracts Tests SOLID GoF patterns
Implementation & Operations

Frameworks, vendor SDKs, persistence, CI/CD, observability, infrastructure—kept behind adapters at the edges.

Adapters Runtime CI/CD Observability
ALD is the bridge: it converts business policy into stable, testable decision boundaries so execution can scale.

Business concepts → ALD artifacts

ALD gives business language a first-class home in code by mapping capabilities and policies to explicit roles.

Capability / policy to role interface

  • Pricing policy → PricingStrategy
  • Eligibility rule → EligibilityPolicy
  • Risk tolerance → RiskAssessmentPolicy
  • Approval thresholds → ApprovalPolicy
  • Compliance constraints → ComplianceValidator
  • Incentive calculation → IncentiveCalculator

These roles are stable because they reflect decisions, not implementation details.

Contracts as executable agreements

  • DTOs express the business language (Money, AccountId, RiskBand)
  • Unit tests prove behavior and edge cases
  • New business rule = new implementation behind the same role
  • Changes become auditable: “what changed” is obvious

In ALD, tests aren’t an afterthought—they’re the shared definition of “done.”

Example: policy-as-code without a new DSL

Instead of burying rules inside a giant service, ALD makes policies explicit and replaceable. You can keep policy logic in normal code, versioned and tested like everything else.

Role interface (decision boundary)

interface LoanEligibilityPolicy {
  EligibilityResult evaluate(LoanApplication app);
}

Contract tests (business agreement)

// Examples:
// - rejects if LTV exceeds policy limit
// - accepts if income/coverage meets threshold
// - returns reason codes for compliance reporting
Result: Business change pressure becomes manageable because decisions are isolated, testable, and replaceable.

Governance & traceability

ALD creates clean “inspection points” that align with enterprise governance, risk, and compliance needs.

What governance reviews

  • Role interfaces: Are decision boundaries explicit and responsibility-scoped?
  • DTO vocabulary: Does it match business language and invariants?
  • Contract tests: Do they prove policy, edge cases, and error modes?
  • Pattern fit: Are abstractions justified (Strategy, Adapter, Decorator, etc.)?

What execution teams/AI implement

  • Concrete implementations behind stable contracts
  • Adapters for frameworks/vendors (kept at the edges)
  • Operational concerns (logging, retries, telemetry) via composition
  • Refactoring to improve maintainability without changing contracts
Traceability that scales: You can trace a business policy to a role interface and the contract tests that prove it.

Adoption path

Start small: pick one module where policy churn or ambiguity creates risk, then enforce role contracts + tests.

  1. Select a high-change area Pricing, eligibility, compliance, approvals—anywhere business rules evolve frequently.
  2. Extract role interfaces Split “service/repository buckets” into explicit decision points.
  3. Write/approve contract tests Make ambiguity explicit; encode edge cases and reason codes.
  4. Delegate implementation Use AI or teams to implement behind contracts; keep frameworks at the edges.
  5. Scale via a role catalog Create a shared library of policy roles + contract tests across bounded contexts.
Operating principle: Change should add new implementations, not rewrite core logic. Keep contracts stable.