What is model-driven architecture?
Model-driven architecture is an approach to building software in which the central artifact is a formal model of the business domain, and the working system is generated or configured from that model. The model describes the things the business deals with (customers, orders, shipments, policies), the attributes of each, the relationships between them, and the rules that govern them. Database schemas, APIs, user interface screens, validation logic, and integration mappings are derived from the model instead of being written separately by hand. The idea began as a software engineering standard for generating code from platform-independent models and has resurfaced in AI platforms, where the same domain model also defines what data a machine learning model consumes and what an agent may read or change.
The word “model” here means the description of the business domain rather than a machine learning model, although the two meet. In a model-driven AI platform, a predictive model is registered as an object in the domain model, with its inputs and outputs declared as typed attributes of other objects.
How model-driven architecture works
Architects and business analysts define the domain model in a modeling tool or a declarative language, and a type system gives each object a precise definition. The platform then generates the storage layer, exposes each object through an API, builds default screens, and applies the declared rules wherever data enters. When the business changes, for example when a new regulatory field must be captured on every invoice, the field is added to the model once and the change propagates to the database, the API, the screens, and the downstream reports.
Model-driven architecture in practice
A specialty insurer replaces three claims systems inherited through acquisitions. Instead of migrating code, the team defines a single domain model for policies, claims, claimants, adjusters, and payments, with validation rules drawn from the underwriting manuals. Each legacy system is mapped into that model through a canonical transform. New claims screens, the reporting layer, and a fraud scoring model are all built against the model’s types. When a new line of business is added, the analysts extend the model and the application follows, with developers writing code only for behaviors the generator cannot express.
What to watch for
- Generated screens are rarely as good as designed ones, so budget for customization.
- Modeling is a skill, and a poorly structured domain model is harder to fix once systems have been generated from it.
- Check how the platform handles changes to the model after data exists, since migrations are where many model-driven projects stall.
- Ask how much of the generated system can be exported if the platform is replaced.