Expect domain languages to explode. More open, the better (2/8)

In a world where context matters as much as code, the language of the domain must be expressed separately from the code.

A modern domain language must embrace ontological definitions as code, express intent within work context, and enable precise testing.

The future of enterprise software isn't about programming languages. It's about domain languages.

For decades, we've tried to embed business logic into code. Java classes representing loan products. SQL queries capturing underwriting rules. Python scripts orchestrating workflows. The assumption was always the same: express the domain in the language of the programmer.

That assumption is breaking down. Not because programmers aren't capable. But because domains are becoming too complex, too dynamic, and too specialized to be expressed in general-purpose languages.

The Domain-Code Separation

Think about a loan underwriting system. The domain involves concepts like applicant eligibility based on income, credit score, collateral; risk assessment across multiple dimensions; regulatory constraints that vary by geography; and business policies that change quarterly.

A programmer can encode these. But the encoding is lossy. A business analyst looking at the code can't immediately understand whether the logic is correct. A regulator auditing the system can't easily verify compliance. A product manager can't quickly prototype a policy change.

What if the domain language was separate? Not separate in the sense of a different file. Separate in the sense of explicit ontological definitions.

The key insight is that when business rules are written in domain-specific syntax, all stakeholders — not just engineers — can understand, review, and verify them. This transforms how enterprises manage complexity.