Evolution Without Rebuilding

Change the Domain. Derive the Evolution.

Businesses do not remain static.

New products appear.

Processes change.

Regulations evolve.

Markets shift.

Customers behave differently.

Organizations restructure.

Software must change with them.

The traditional response is to modify the codebase repeatedly until it reflects the new reality.

HexaKernel proposes a different model.

Evolve the Specification

If the domain is represented explicitly, a change can begin at the domain level.

A new rule becomes a specification change.

A new process becomes a specification change.

A new state becomes a specification change.

A new relationship becomes a specification change.

The software can then be regenerated, adapted or extended from the new version.

The Specification Has a History

Versioning the specification creates a history of how the domain itself has evolved.

This makes changes more understandable.

It becomes possible to ask:

What did the domain mean before?

What changed?

Why did it change?

What software should exist for this version?

What tests should validate it?

What documentation should describe it?

The evolution of software becomes connected to the evolution of the business.

Reduce Rebuilding

The objective is not to eliminate software development.

It is to eliminate unnecessary reconstruction.

The reusable asset is no longer only the codebase.

It is the formal knowledge of the domain.

That knowledge can survive changes in implementation, technology and AI.

Evolve the specification, and let the software evolve with it.

Privacy Policy * Legal Notice * Cookie Policy * Terms of Use * Terms of Service * Intellectual Property * Security * Data Processing * Accessibility