There are a lot of questions and answers about what a/the model is. Particularly when discussing where business logic belongs and the MVC pattern. There seem to be two concepts that need to be severed. I hope a question to this specific clarification has value.

The options are:

  1. A simple data carrier. No thinking except maybe some basic validation. (eg. POJOs/POCOs, View Models, classes mapped to database tables) (eg. here and here).
  2. An entire layer (or even group of layers) that comprise all business logic and data access (eg. here, here and here. A model can be almost anything).

The term model seems to have suffered beyond recovery. People are changing their architecture without realizing that the term is ambiguous.

Perhaps the perfect example of this ambiguity is Microsoft's architectural diagram of MVC: The MVC pattern is clearly located in the UI layer, but the concept of a model clearly spans every layer.

enter image description here

This is very confusing for both new comers and experienced software engineers.

I would like to point out that option 2 does not correspond in any way to the definitions of the word model. That does not help.

My questions are:

  1. Have I missed something important or does this accurately describe what has happened to the term model?
  2. Considering option 2 is unintuitive, don't we have better words for these different layers (like services, repositories, etc.)?
  • 3
    Perhaps you should read the MS picture like: left side shows the Layer where Model mentioned on the right side lives. Aug 4, 2018 at 17:06
  • 1
    The dictionary definitions that you linked to are a bit generic; here is a better definition: en.wikipedia.org/wiki/Domain_model Aug 4, 2018 at 20:34
  • I'm surprisingly pleased to see that Wikipedia's description of the Domain Model corresponds to Microsoft's architectural diagram above. The waters are slowly clearing for me. So that's what I should call the "domain model". Got it! I would still rather call it the (business) service layer and stop using the term model for everything.
    – MyiEye
    Aug 4, 2018 at 20:44
  • 1
    I would still rather call it the (business) service layer and stop using the term model for everything you didn't get it :-) Note that EVERYTHING is a model. As soon as a data structure provides with functionality and data to a domain problem is, in its own right, a model. No matter if it's related to your business or not. SMTP servers have their own models, message brokers, app containers, etc. Everything in software engineering happens within a bounded context. The one we call domain or business. The data structure that shape it is and will be always the model.
    – Laiv
    Aug 4, 2018 at 21:05
  • 1
    Make clear first the scope you are referring to. Then you can speak with no ambiguity about the data models, domain models, etc. What you call"service layer", "controller layer", "persitence layer" are just "scopes" and every scope might (should) have its own model. For the sake of decoupling
    – Laiv
    Aug 4, 2018 at 21:08

6 Answers 6


One issue with these discussions is the all-to-frequent mixing of different architectural viewpoints in the same discussion or diagram.

  • Some architectural viewpoints are meant to show depth: deep dives into how some particular functionality is implemented.
  • Whereas other architectural viewpoints are intended to show breadth: the interactions of components that are peers (that exist at the same level in terms of depth).

Mixing both viewpoints (depth and breadth) together in the same diagram tends to lead to confusion.  In surveying the sources your citing, I find no shortage of this kind of mixing of these what would more ideally be separated architectural viewpoints.

For example, the diagram you're showing (citing Microsoft), you have said MS claims to be an MVC diagram, but it is primarily showing depth in the domain model, with overweight focus on persistence (from the MVC perspective). So, this diagram is weak on the breadth viewpoint of interacting peers (M,V,C) and mixes in some depth viewpoints with persistence: broken out (and elevated to be a peer of the other components).  It is understandable that one might question where the domain-logic belongs given the-all-to-easy-to-mix architectural viewpoints.

In MVC, the model is what is responsible for maintaining domain objects, responding to domain-oriented queries & commands (including validation, etc..), and enforcing/effecting domain-oriented rules & behaviors.  MVC doesn't speak to breaking out persistence: if your system includes persistence that is an implementation detail (detail of depth, not of breadth).  Thus, there is no question as to where domain-logic belongs in MVC, or whether domain-objects should be dumb or smart — these questions are all internal aspects (implementation details) of the model.

You are also correct that the term Model is overloaded and over used.  So, what the term means has to be evaluated in some context.  Unfortunately, many of these discussions fail to set or keep context, adding to confusion.

In MVC, the term Model means what I mentioned above (keeper of domain objects, handler of queries & commands..).  We might speak of POJO's, and such discussion should apply to the interactions between the peers M,V,C, and whether the query & command interface to the model uses dumber or smarter objects.

In detailing persistence — an implementation detail from the MVC perspective — we can speak to POJO's, or smart/dumb at different places in the persistence mechanism, we can even reuse the term model at different interfaces in the implementation details of persistence.

In summary, it is possible for the term model to be used in both ways you're describing — it is not either/or.  What makes things confusing is that we often fail to set context, and/or fail to show when we're shifting context from breadth (interacting of peer components) to depth (implementation detail of usually of one of these component).

  • Good insight. Can I summarize your answer regarding terminology as: "the term is indeed strongly ambiguous and we will simply have to learn to contextualize it for the rest of our lives"? Or are you saying that option 1 (eg. POJO's) is simply part of the option-2-model, which is ultimately the correct meaning?
    – MyiEye
    Aug 4, 2018 at 17:54
  • Both in some sense. Regarding the former, yes, the term model is context sensitive. Regarding the latter, yes, though rather than describing the model as a layer, I would maybe call it a component of MVC; a component whose implementation detail isn't specified by MVC, but we can certainly talk about it by shifting to another context.
    – Erik Eidt
    Aug 4, 2018 at 18:12
  • So would you say it's correct to label the combination of "view models" (for presentation), "domain models" (for business/domain logic) and "data models" (for performing persistence)" as the model of an application?
    – MyiEye
    Aug 4, 2018 at 20:50

In MVC, the Model is anything that is not part of the View or the Controller. In MVVM, the Model is anything that is not part of the View or the ViewModel. That should be easy enough to remember.

If that definition doesn't satisfy you, then think of the Model as all of those components that relate directly to your problem domain, such as a Customer class or an Invoice class. Everything else is part of a UI abstraction, which is all MVC and MVVM really is.

In other words, MVC and MVVM really have nothing to say about the Model, from an architectural perspective. The structure and organization of the Model is entirely up to you; MVC and MVVM concern themselves primarily with the other components (view, view model, controller).

Further Reading
Domain model from Wikipedia

  • So option number 2?
    – MyiEye
    Aug 4, 2018 at 16:16
  • I appreciate a friendly answer to a relatively sharp question, but it feel like you're just choosing a side. There seem to be a good number of people on the other side as well (as I referenced). And in ASP.NET MVC I pass my model to the view. Should I pass it "anything that is not part of the View or the Controller"?
    – MyiEye
    Aug 4, 2018 at 16:25
  • There are no "sides" here. The model are those data structures that represent your business or problem domain. If you're trying to extract more meaning out of the word "model" than that, you're over-thinking it. Aug 4, 2018 at 20:32
  • I guess you're specifically talking about the "domain model". Which does not include how the data is persisted or what form it's in when it gets passed to a view.
    – MyiEye
    Aug 4, 2018 at 20:47
  • 2
    In the context of MVC and MVVM, the "Model" is your option two. In your question you state that "The MVC pattern is clearly located in the UI layer, but the concept of a model clearly spans every layer." That is correct only in the sense that MVC points to a "Model." But MVC concerns itself mostly with the View-Controller part. MVC doesn't have much to say about the model, other than there is one. Aug 4, 2018 at 21:03

The model is not "everything else". The model is the number behind 3.14159... It is not "3.14159265". It is not the button you push to get pi. It is not the paper you write π on. It is not the blinking lights you use to communicate the ratio of a circles circumference to its diameter. It's the number, however you choose to model that, that you use when calculating other fun stuff like waves, rolling tires, and rotated text.

Now sure, half tau is just a dumb constant that you can pull out of a library but the point is you have to decide how you model things based on your modeling needs. This is how your application thinks of the world. That's what a model is. How to show, manipulate, remember, communicate, or any other thing besides modeling is not the models job.

You can put business rules in the model. But those rules had better be about modeling something. Not anything else.

If following these rules means you have no where to put something fine. Make somewhere new to keep it. You will make an ungodly mess if you blindly follow prepackaged designs rather the pay attention to what your problem is telling you that you need.

  • This sounds very similar to option #1. Is it the same? If not, could you spell out the difference for me?
    – MyiEye
    Aug 4, 2018 at 16:59
  • I've told you what a model provides you, not how to implement one. 1 and 2 are both simply ways to model. Both must provide a model. If you think those two are the only ways then you underestimating how old MVC is. This is the primordial soup that design patterns & architecture sprang from. You can find this done a multitude of ways. If there is a one true implementation I haven found it in decades of looking. I don't think anyone has. Just hold onto the idea that the model is how your app understands the world. Aug 4, 2018 at 23:04
  • You're being particularly vague about what defines a model or the act of modeling. You seem to rely on the assumption that one can derive the definition of "model" by inherently understanding what "modeling" means, which is in no way a given. They are simply the verb/noun forms of the same concept. If you understand one, you understand the other. any other thing besides modeling is not the models job That's a semantical inevitability. That's like saying "the database only handles database-related stuff".
    – Flater
    Aug 6, 2018 at 10:46
  • @Flater I'm pointing out that the only consistent rule with models is that they have the single responsibility of modeling. You can hold your breath and stamp your foot demanding more but that's all there is here. A simple tautology. Everything else that's been done about the model is just personal flavors where one is no more correct to call a model than the other. In short I'm being vague because it is vague. Aug 6, 2018 at 13:31
  • @candied_orange but that's all there is here. A simple tautology. If there wasn't anything more to it, then no one would know what modeling actually entailed, making the concept moot. There's a difference between not having a definition and it not being easy to give a clear and umambiguous definition.
    – Flater
    Aug 6, 2018 at 13:57

In clarifying the term Model, let us start with the definitions in Trygve Reenskaug's original notes on the MVC concept written in 1979.

A Model is an active representation of an abstraction in the form of data in a computing system.

Models represent knowledge. A model could be a single object (rather uninteresting), or it could be some structure of objects.

In the comments following the definition of a Model in the first paper, Reenskaug gives an outline of how the Model should be represented in a computer.

The models are represented ... as a collection of data together with the methods necessary to process these data.
Ideally, all models should be totally consistent.

Reenskaug appears to be defining two concepts with a single word. Models are both an abstraction to be represented in the computer and also a representation of an abstraction. A distinction needs to be made between these: the Model as an abstraction and the Model as a representation of that abstraction.

Another description is offered by Steve Burbeck in his paper providing information essential for new Smalltalk-80 programmers.

[T]he model manages the behavior and data of the application domain
How to use Model-View-Controller

which also considers the Model as an active representation.

In 1980 a paper by Ted Codd was first published. In it a Data Model is defined as...

...a combination of three components:

  1. a collection of data structure types (the building blocks of any database that conforms to the model);
  2. a collection of operators or inferencing rules, which can be applied to any valid instances of the data types listed in (1), to retrieve or derive data from any parts of those structures in any combinations desired;
  3. a collection of general integrity rules, which implicitly or explicitly define the set of consistent database states or changes of state or both.

Data Models in Database Management

Chris Date has also defined a Data Model as...

...an abstract, self-contained, logical definition of the objects, operators, and so forth, that together constitute the abstract machine with which users interact. The objects allow us to model the structure of data. The operators allow us to model its behavior.
An Introduction to Database Systems (Eighth Edition)

In these definitions a Data Model is a formal abstraction. The components match with those Reenskaug states should comprise the Model to be represented in the computer. Therefore, it is concluded that a Model as an abstraction is a Data Model.

A DBMS implements a Data Model. It allows users to create a structure of object types; create or use a predefined collection of operators to process that data; and declare and/or implement constraints to ensure the data is consistent. Therefore, it is concluded that the Model as a representation of an abstraction - i.e. the Model component of a MVC framework - is a DBMS.


Let's take a step back.

Regardless all the other distracting definitions of the word, in technology a model is a workable picture of a problem, an analogy, something that allows you to communicate about a creation. There may be many models to the same thing that all make sense. And one model may work for more than one thing. Like a tree with a stem and branches is a model that works for a lot of technical stuff.

In software modeling, the model is most often an unspecified part of the system. It is unspecified because it is different for each application. And therefore confusing. You have your database (pretty concrete, who doesn't have one?), you have your UI (alright, I know what that is), and then you have something in between that is up to you do define and work out, that is the core of your application, that makes your application different from other applications that follow the same design principles. That would be your "model".


As far as your questions:

  1. I do feel that you are missing something with both of the provided concepts on models.

  2. In certain cases, those other names are not necessarily at the same level as model, but they can be things part of the model.

That is not to say that there are instances where the distinctions you see just don't happen.

I have a few things that I try to keep in perspective when approaching some kind of model.

From the model itself:

  • what should I (the model) know about myself?

    • something like should I know my position if I make up a list of things, or should I know the items/formula/constraint used to define my exposed value

From anything that calls the model:

  • Do I provide the results of a formula/constraint to the model, or should I be agnostic of how the result was determined?

    • something like position (x & y, or some group of containers) to determine some value or derived rule that the model doesn't need to parse/determine

So, there are cases where different pieces of business logic is in a place that they don't belong, but that really depends on the overall intent of some app or domain which can still change over time.

For the concept of better names, the reason for stating whether something like service or repository is not necessarily on the same level is for the same reasoning stated above.

  • As a service, is my result something that is used to be the model, or am I used to derive some other value associated to the model?
  • "those other names are not necessarily at the same level as model". At the same level conceptually or architecturally (i.e. layer)?
    – MyiEye
    Aug 4, 2018 at 17:57
  • For me, I try to use the viewpoint conceptually, since I tend to lose focus when I try to use it architecturally. I do try to let the idea show in the design, where some poco, or whatever you use, can easily show intent. Aug 4, 2018 at 18:23

Not the answer you're looking for? Browse other questions tagged or ask your own question.