The Architecture

Supermodel MVC Architecture

With Domain Driven Design, we always start with Entities. Entities are classes defining the world in which your application operates, and comprise the domain model of your application. Entities persist in the Database using the Database Schema. However, Entities should have no knowledge or awareness of how and where they're stored. It is okay (good, even) to know that they can be persisted, though. So, another layer called Repositories is added to our architecture. This layer can take an Entity and store it in the database or take a database representation of an Entity and unroll it in memory. We also need a way to manage our transactions. In other words, we need to be able to take multiple operations that happen across multiple Entities and across multiple Repositories and make them atomic: they must all succeed or they all fail. There's a concept in Supermodel called Unit Of Work that takes care of this for us.

Our presentation layer includes Controllers and Views. Controllers orchestrate user interactions and Views generate/render the presentation for the User. Entities should not be entangled with our presentation layer. Instead of using Entities in our front-end directly, we introduce another layer called View Models. View Models could be MVC Models or Web API Models. Entity Mappers know how to take an Entity and make a View Model out of it, or take a View Model and make an Entity out of it. Base View Models provide such mapping for free using reflection. When data comes back from the HTML page, we need to bind it to the View Model, which is where the Model Binder comes into play. Next, View Templates take a Model and render the HTML representation for it. Finally, the Validation layer allows us to validate data submitted by the User and also make sure that our database maintains integrity when Entities are stored there.

In this architecture, MVC Models know how to:

Validate themselves
Map to and from Entities
Render themselves in HTML using View Templates
Bind themselves to the user input using Model Binders

All of that functionality is already defined through the base MVC Models by convention, but can be overridden in case you want to do something different from the default.

Using Supermodel, MVC Models and Entities are the only things we absolutely have to supply. Everything else has a default implementation and is provided to you by the Supermodel framework. You can enhance or replace it should you need to do something that is different from the default. Ninety percent of the time, however, the default is what you're going to want.

Supermodel Web API Architecture

The Web API architecture is very similar to the MVC architecture, except for the fact that Web API's do not have a presentation layer. Therefore, we remove the Views and View Templates from the architecture and are left with the following:

Just like in the MVC world, when you're using Supermodel, API Models and Entities are the only things we absolutely have to supply. Everything else has a default implementation and is provided to you by the Supermodel framework with the ability to replace it should you need to do something that is different from the default.