Why Reconstruct Software Development Methodology?

Part 1 at a glance: treating the Domain Model as a working abstraction connected to implementation.

The history of software development can be understood as a history of abstraction.

Each advance in abstraction has moved human work upward. Instead of arranging machine instructions directly, developers describe types and functions in high-level languages. Instead of repeatedly implementing common behavior, they use libraries. Instead of assembling all application control from scratch, they place application-specific behavior within structures provided by frameworks.

This change does not mean that details ceased to matter. It means that reliable mechanisms took responsibility for those details, allowing humans to concentrate on higher-level problems.

Domain models have existed for a long time. In many cases, however, they remained views of the problem domain without a direct connection to implementation. Object-oriented languages such as Java, design conventions, and code generation have all been used to align domain models with implementations, but much of the transformation still depended on humans, leaving a substantial gap between model and implementation.

With the arrival of AI, the domain model has become a new working abstraction primarily handled by humans. Here, a working abstraction means an abstraction with a realization path to implementation that can directly drive development forward. AI interprets domain models, translates them into implementations, and fills in the required implementation details. Textus then provides the execution platform, establishing a path from domain models to executable software. The domain model can therefore function not as an analysis document detached from implementation, but as a software development abstraction connected to implementation.

Every successful abstraction has a reliable means of reaching the lower layer.

High-level languages did not make machine language unnecessary. Compilers translate high-level languages into machine language, so humans no longer need to write machine instructions directly. Frameworks did not eliminate runtime processing either. Their runtimes take responsibility for common control, allowing developers to focus on application-specific concerns.

Abstraction therefore requires more than creating abstract representations. It needs a path from those representations to executable software. Abstraction and realization are a paired mechanism supporting software engineering.

SimpleModeling defines a domain model as a view of the problem domain and a working abstraction primarily handled by humans. AI translates domain models into implementations and fills in the necessary implementation details. Textus provides the execution platform for realizing the resulting software. Together, they establish a path from domain models to implementation and execution.

AI increasingly assists with and performs program generation, modification, testing, refactoring, and other implementation work.

This does not mean that programming itself disappears. Generated software is still composed and executed through programming languages, libraries, frameworks, and runtimes. What changes is not the existence of programming, but where humans participate in that work.

When asking AI to implement software, humans must specify what should be built, which constraints must be preserved, where responsibilities belong, and what counts as a correct result. Instead of directly specifying each line of code, the important work becomes providing the meaning and structure on which implementation depends.

In this process, AI translates domain models into implementations and fills in the necessary implementation details. This work connects domain models to implementation.

Modeling is the activity of expressing this meaning and structure.

Software modeling here means more than drawing diagrams. It clarifies, through different views, how the problem domain is understood, what responsibilities software elements have, how execution proceeds, and how knowledge is structured. A domain model is the view of the problem domain within this broader modeling activity.

The shift of human work from programming to modeling does not mean that humans will never write code. It means that the primary subject humans must directly design for development to succeed shifts from code construction to model construction.

As AI accelerates implementation, ambiguity and contradictions in models also reach implementation faster. When the structure is unclear, AI may generate code that works locally while failing to preserve responsibilities and consistency across the system.

When goals, terminology, responsibilities, boundaries, and execution rules are modeled clearly and consistently, AI can interpret that structure and more readily implement, validate, and modify the software. Clarity and consistency, however, do not mean that the model is valid and accurate with respect to actual business needs and requirements. AI will also faithfully implement a clearly described but incorrect model.

Software quality therefore depends more strongly than before on the quality of modeling.

Modeling becomes the new choke point of software development.

This means more than saying that modeling becomes important. As implementation capability becomes widely available through AI, the source of differences in development outcomes shifts from the amount of implementation to what is modeled and how it is modeled.

SimpleModeling treats model accuracy as something that cannot be established all at once. It provides a mechanism in which domain experts, developers, and AI collaborate to iteratively improve domain model accuracy, using a glossary, use cases, BoK, and the domain model metamodel as a shared foundation.

The three parties construct domain models from this shared knowledge and use cases to evaluate their validity for business scenarios. They reflect identified omissions and contradictions in the BoK, terminology, constraints, and models, after which AI updates the implementation. Repeating this cycle improves the accuracy of both models and implementations.

Domain experts confirm business knowledge and model validity, while developers examine model structure, constraints, and feasibility. AI refers to the BoK to help organize knowledge, identify contradictions and omissions, and support modeling. Rather than relying on AI alone to generate a correct model, the three parties continuously improve the model through collaboration and iteration.

Existing software engineering provides many valuable techniques, including object orientation, design patterns, domain-driven design, CQRS, and knowledge graphs. AI does not diminish their value.

However, when the abstraction level handled directly by humans changes, the roles and uses of individual techniques must be reorganized. A body of knowledge listing techniques alone cannot determine which techniques to select, which design decisions to fix, or how development should proceed.

What is needed is to select existing techniques around modeling, define their respective roles, and integrate them into a development approach that reaches executable software from abstraction. This is why software development methodology must be reconstructed.

SimpleModeling does not aim to collect individual technologies newly appearing in the AI era. It selects existing software engineering knowledge from a modeling-centered viewpoint and organizes it into a concrete software development methodology.

Literate Model-Driven Cloud-Native Development with Object-Functional Paradigms for the AI Era

Under this phrase, SimpleModeling.org uses Literate Model-Driven development, Cloud-Native development, and Object-Functional paradigms as the three axes of its methodology.

Nor is producing models an end in itself. Software engineering requires both abstraction and a realization path connecting that abstraction to executable software. Throughout this series, we will explain how SimpleModeling constructs this path.

SimpleModeling’s model-centered direction did not begin with the arrival of AI. Through CML, DSLs, Literate Modeling, and executable models, it has long pursued a path from models to executable software.

The next article, "What SimpleModeling Has Pursued," will explain this historical continuity and how AI complements the transformation from knowledge to models.