Introduction

A concern, in software, is all the code related to a particular aspect of the software: the user interface, accessing the database, calling a web service, logging etc.

A layered architecture is an architecture where the different concerns of the application are separated into different layers. A layer can interact directly with the layer below it by manipulating the objects that are publically accessible. The lower layer communicates with the layer above in a more decoupled way, usually using some eventing mechanism. Minimize what the layer above knows about the layer below, in terms of data, behaviour and most certainly implementation. This should ensure that the layers are loosely coupled, but highly cohesive. This is shown below.

The software may also be structured within a layer. This structuring would usually be grouped according to function within the system; for example according to use case, user story, business function etc. The layer may also contain common infrastructure type code, used by each grouping. This is shown below.

If the infrastructure code is not application-specific then it should be moved to a library module for inclusion in multiple applications.

Specific Layering

MVC, MVP and MVVM are all layered architectures. They essentially all say the same thing, distinguished by minor implementation details. The diagram below describes these architectures in more detail.

The Model

In layered architectures, the M refers to the domain model. A domain model is a conceptual model: including data; its structure and behaviour, which describes the software to be developed.

The domain model is started during analysis. The real world is made up of objects with properties, behaviour, relationships and interactions with other objects. Through a process of abstraction the objects, their properties, behaviour and relationships important to the problem at hand are turned into classes with properties, methods and relationships to other classes. The lifecycle of classes with interesting lifecycles are also described.

The domain model is the bases of all development activities: database design, user interface design, the system and software architecture. It is also the bases of the M in all the software components that use a layered architecture.

The domain model is even the bases of the agile practices (Ubiquitous Language). The bedrock of agile is the maximizing of the application of the knowledge gained during the development process. It is for this reason that the domain model started during analysis, should be extended and enhanced during design and implementation until it eventually appears in the code.

There is no confusion about what the M is.

Apple prescribes MVC and has this to say about the Model: “Model objects encapsulate the data specific to an application and define the logic and computation that manipulate and process that data. For example, a model object might represent a character in a game or a contact in an address book. A model object can have to-one and to-many relationships with other model objects, and so sometimes the model layer of an application effectively is one or more object graphs. Much of the data that is part of the persistent state of the application (whether that persistent state is stored in files or databases) should reside in the model objects after the data is loaded into the application. Because model objects represent knowledge and expertise related to a specific problem domain, they can be reused in similar problem domains. Ideally, a model object should have no explicit connection to the view objects that present its data and allow users to edit that data—it should not be concerned with user-interface and presentation issues.”

Microsoft prescribes MVC and has this to say about the Model: “The model in MVVM is an implementation of the application’s domain model that includes a data model along with business and validation logic. Examples of model objects include repositories, business objects, data transfer objects (DTOs), Plain Old CLR Objects (POCOs), and generated entity and proxy objects.”