Language-Driven Design (LDD) Manifesto

Software systems are a reflection of the language governing their operational domain. Ambiguity or flaws in language lead to ambiguity or flaws in the system itself.

Each entity, service, or process in the system should reflect a specific concept in the domain language. The system’s architecture must be a reflection of the business language, not just a collection of technical components.

Multiple interpretations of a term lead to confusion and misunderstanding. Thus, clarity in language holds higher priority. Each term should have a unique meaning, and each concept should be clear and precise.

Business changes and user needs require the evolution of the domain language. Continuous documentation, analysis, and updating of language are necessary to keep it aligned with reality.

The boundaries of the system architecture should align with the conceptual boundaries of the domain language. Every service, module, or API should represent a clear concept from the domain language.

The success of a system depends not only on suitable code but also on a shared understanding between technical and non-technical teams. A clear and common language facilitates communication and reduces the gap between these teams.

Naming entities, services, APIs, and system messages is a decision beyond personal preference. Proper naming enhances clarity, reduces complexity, and prevents misunderstandings.

The software system must be understandable by both humans and machines. A language that is consistent in code, documentation, and daily team interactions is essential.

Dividing the system based purely on technical structures is insufficient. System boundaries must align with the boundaries of the language and their meaning in the real world.

The language used in system design must be in harmony with the language of end users. System terminology should reflect users' understanding of processes and concepts.

As the system grows, the language must also have the ability to scale. Any changes to the language must be deliberate and controlled.

The data model should not be separate from the domain language. Domain language terms should be clearly represented in the data model.

The complexity of software systems often arises from ambiguity in concepts and terms. A clear and precise language design reduces unnecessary complexity.

Documenting the domain language and all its changes must be continuous and living. These documents should be easily accessible and usable by all team members.

Holding collaborative sessions with all stakeholders (technical teams, users, and managers) is essential to arrive at a shared language.

Continuous feedback from users and stakeholders ensures that the domain language evolves in alignment with real needs.

In conversations and documentation, avoid domain-specific programming jargon, opting for simple, understandable language that everyone can comprehend.

The language must continuously evolve in alignment with new needs and changes in the real world. This process occurs continuously and through close collaboration among all stakeholders.

A shared language not only plays a crucial role in system design but also in team collaboration. Effective interactions between team members, based on a common language, create more successful paths for projects.

The language should be designed in such a way that it simplifies complexities and makes intricate processes more understandable and manageable.

At LDD, we aim to maintain the language as small and closed as possible. By adopting the concept of "closure" from mathematics, we avoid introducing unnecessary terms or concepts into the language. This means that the language should evolve only with deliberate and necessary additions, ensuring it remains precise, simple, and free from unnecessary complexity. This closure approach helps us keep the language clear, focused, and effective.