You can use this page to understand model-driven development and adopt the model-first workflow used by MDriven.
What model-driven development means
Model-driven development (MDD) is a way of developing software in which the model is the core definition and template for the artifacts needed in the finished product. You make changes in the model first, then update the artifacts derived from it.
A model is a structured, abstract representation of the system that captures essential information, relationships, and behavior. In MDriven, the model can define application data, business logic, and user-interface structure.
For example, if an application needs to store customers and their orders, you first describe the customer and order information and their relationship in the model. MDriven can then use that model when producing derived artifacts such as a relational database schema, C# code, and ViewModels. When the order information changes, update the model before updating the derived artifacts.
Align your work to the model
In a model-first workflow, treat the model as the central definition of the system rather than as documentation that follows handwritten implementation.
- Describe the domain in the model. Use domain terms and definitions that match the system you are building.
- Add rules and behavior to the model. Use OCL (Object Constraint Language) for expressions that retrieve or manipulate data and for business rules.
- Create a ViewModel when you need to shape model data for a user-interface use case. A ViewModel defines how the application looks and behaves without changing the domain model for that specific presentation need.
- Derive or update the required artifacts from the changed model. MDriven can transform the model into C# code and relational database schemas, and can apply the model in the UI layer through ViewModels.
- Keep handwritten additions separate from generated domain-layer code by using partial classes when you extend generated code.
What changes first
When a requirement changes, identify the change in the model before changing generated or handwritten artifacts.
| Requirement change | Model-first action | Example |
|---|---|---|
| A new piece of business information is needed | Add it to the model, then update derived artifacts. | Add a required order reference to the order information before updating the database schema and UI. |
| A business rule changes | Update the rule in the model. | Change the rule that determines whether an order can proceed, rather than duplicating the rule in several UI screens. |
| A screen needs a different presentation of existing information | Create or adjust a ViewModel. | Show customer name and order status together in a ViewModel without changing the underlying customer and order definitions. |
Keep the distinction clear
MDD does not mean that every artifact must be generated. An artifact can be derived through automation or made by hand. The defining practice is that the model remains the core definition and that changes start there.
MDriven is model-centric: changes go into the model first and then flow to code and other derived artifacts. MDriven uses Visual Studio re-engineering capabilities to apply model changes throughout code, and its built-in evolve function updates an existing database toward the form described by the model using nonintrusive methods where possible.