You can use this page to distinguish Model-Driven Architecture (MDA), Model-Driven Development (MDD), and Domain-Driven Design (DDD) and apply them together when you build an MDriven solution.
The three terms at a glance
| Term | What it describes | What you do in an MDriven project |
|---|---|---|
| MDA — Model-Driven Architecture | Using a platform-independent model as the basis for technical artifacts and runtime behavior. | Describe the business information in a UML model, then use that model for generated code, database structure, user-interface definitions, and persistence behavior. |
| MDD — Model-Driven Development | Organizing development so that the model is the primary definition and changes begin there. | Change the model first, then update the artifacts derived from it, including code and the database schema. |
| DDD — Domain-Driven Design | Modeling with the terms and distinctions used by the business domain. | Name classes, attributes, associations, and rules in the language that domain experts use, so the model is a shared definition of the business. |
These approaches address different questions. MDA describes how a model can be applied to implementation artifacts. MDD describes the development workflow around that model. DDD describes how you express the business in the model. You can use all three together.
Model-Driven Architecture (MDA)
Model-Driven Architecture (MDA) is the approach of describing an information system in a platform-independent model (PIM) and transforming or applying that model to the artifacts that form the solution.
A platform-independent model (PIM) captures the information design without making that definition depend on a particular implementation technology. Keeping this definition separate protects the investment in the business design when implementation technologies change.
In MDriven, you create and maintain the UML model in MDriven Designer. MDriven Designer can be used as a standalone modeling and execution tool, and MDriven is also available as a Visual Studio plug-in for development that includes derived code, derived database scripts, and database evolution.
Apply one model in several places
MDriven uses the model in more than one part of the solution:
- Domain code: MDriven can transform the model into C# code.
- Persistence: MDriven uses a persistence mapper to hydrate objects from persistent storage and dehydrate them back to storage. This is object-relational mapping (ORM): application objects are translated to the operations needed to create, read, update, and delete their stored representation.
- Database structure: the database schema can be derived from the model and evolved as the model changes.
- User interface: a ViewModel is a set of transformation expressions that presents part of the model in a form suitable for a user interface. ViewModels can also contain UI hints that declaratively guide UI generation.
- Runtime use: MDriven can use the model on a server as an ORM layer for services that follow the model.
For example, a business may model a Customer class, an Order class, and the association between them. The same model can define the domain objects, inform the persistent database structure, and supply the source data for a ViewModel that lists a customer's orders. The model remains the shared definition; each artifact applies that definition for a different purpose.
= ViewModels are model transformations, not copies of the domain
Do not treat a ViewModel as a second domain model. Use it to transform and present the part of the domain a user needs for a task.
For example, an order-entry ViewModel can show an order, its customer, and its order lines. It can use UI hints to present those values as a working screen while the underlying Customer, Order, and OrderLine definitions remain in the UML model. This separates the business definition from a particular screen layout or client technology.
Model-Driven Development (MDD)
Model-Driven Development (MDD) means that the model is the core definition for development. When the business changes, make the change in the model first and then update the artifacts derived from it.
This workflow avoids maintaining separate, diverging definitions of the same business rule in model diagrams, code, database scripts, and UI code.
Use a model-first change workflow
When a requirement changes, use this sequence:
- Update the UML model in MDriven Designer. Add, remove, or change the class, attribute, association, or rule that represents the business change.
- Review affected ViewModels and actions. Update their transformations and UI hints when the user's task has changed.
- Update derived code. Keep handwritten domain additions separate by using partial classes.
- Apply database evolution so that the existing database moves from its current structure to the structure described by the updated model.
- Test the changed behavior through the relevant ViewModels and application flows.
For example, if an order must record a requested delivery date, first add the delivery-date attribute to Order in the model. Next, add it to the order-entry ViewModel where users need to enter it. Then update derived code and evolve the database schema. Do not begin by adding a database column or a handwritten property and try to reconstruct the model afterward.
Preserve handwritten additions deliberately
Generation does not require all application behavior to be generated. MDriven supports a model-centric approach in which generated domain code is updated from the model while handwritten additions are kept in partial classes. Visual Studio re-engineering capabilities can apply model changes throughout code.
The important rule is ownership: the model owns the domain definition. Handwritten code may extend the derived domain layer, but it should not become a competing definition of the classes and relationships that the model owns.
Evolve the database from the model
MDriven includes database evolution that updates an existing database toward the form described by the model. The goal is to use nonintrusive changes where possible rather than require a new database for each model revision.
Review a model change for its data consequences. Adding a new optional attribute differs from removing an attribute that contains existing data. The model-first workflow makes that impact visible before the database update is applied.
Domain-Driven Design (DDD)
Domain-Driven Design (DDD) means that your model uses the language and distinctions of the business domain. The model becomes a shared vocabulary for domain experts, modelers, developers, and stakeholders.
DDD is not defined by code generation, UI generation, or a specific persistence technology. It is the modeling discipline that determines whether the terms in the model describe the business meaningfully.
Model the business language
Use names that domain experts recognize and can review.
| Less domain-specific name | Domain-driven name | Why the second name is clearer |
|---|---|---|
Entity
|
Order
|
It identifies the business concept being managed. |
Item
|
OrderLine
|
It states the item's role within an order. |
StatusCode
|
DeliveryStatus
|
It states what the status represents. |
A reusable or abstract model can still be useful, but it is not DDD when its names deliberately avoid the language of the domain. For instance, a generic Party concept may support several domains; where the business speaks specifically about customers, suppliers, or patients, those distinctions must be clear in the model if they matter to the business.
Use the model as a reviewable business definition
Review the model with people who understand the domain. Ask whether each class, association, attribute, and rule corresponds to something they recognize in their work.
For example, if a business expert says that an order cannot be sent until it has an approved delivery address, represent the concepts and the constraint in the model. The model can then communicate the rule to both business and technical participants, rather than leaving it only in a developer's implementation.
The broader goal is to keep the model aligned with the business reality it supports. Theoretical Best Model discusses continuous refinement of that business definition.
How the approaches work together
Use DDD to decide what the model says. Use MDD to decide how changes are made and propagated. Use MDA to decide how the model is applied to implementation artifacts and runtime behavior.
A typical MDriven flow is:
- Work with domain experts to define the business concepts and language in the UML model (DDD).
- Make the model the first place for every domain change (MDD).
- Derive or apply the model to code, persistence, database structure, and ViewModels (MDA).
- Execute and review the resulting application behavior, then refine the model as the domain changes.
Practical guidance
- Keep business concepts in the model. Avoid making the database schema or a UI screen the only place where a business distinction is defined.
- Change the model before changing derived artifacts. This keeps code, schema, and UI definitions aligned with the intended domain definition.
- Use ViewModels for task-specific presentation and transformation of model data; do not duplicate the domain model in each UI.
- Use partial classes for handwritten domain-layer additions so that derived code can be updated without overwriting those additions.
- Choose names that business users understand. If a term cannot be explained to a domain expert, reconsider whether it belongs in the domain model.
- Inspect the model regularly. A published, read-only model can help people navigate classes, ViewModels, actions, and their cross-references; see ModelMeta.