Confusion between domain model and presentation model

[Don Kiddick]

Hello!

I am building an application. The application is a container for other applications. We are able to host components built from other teams, provide different layout configurations and provide transitions to that layout when events are raised by the components.

We have a pojo-based model. That main entities in the model are things like
* Component : the components other teams write
* Frame : a layout element that components can be placed on
* Transition : something that happens when an event is raised by a component - often results in frames being hidden/shown/moved etc.

I'm confused whether this is a domain model (where our domain is the ui) or a presentation model (in which case we don't really have a domain model).

Why does this matter?

Well the model ultimately gets realised with some ui widgets - in this case swing and jide. So far we have avoided having any jide or swing specific code in our model. The ui layer though is proving hard to unit test, and so I want it to be as dumb as possible. So I want to move the logic currently inside the ui into a model of some sort. The two main choices I see are :
1. Moving the logic inside our existing model. This means moving (polluting?) our model with Swing/Jide specific references.
2. Creating a presentation model, which sits between our existing model and the ui.

1. seems somewhat 'wrong' if I consider our existing model to be a domain model - having jide and swing specific reference doesn't seem good. It is however simpler.
2. seems cleaner...but also more complicated...am I maybe overcomplicating things?

regards,
D.

[Tim Holloway]

Well, for what it's worth, my usage of the term "Domain model" is the set of ORM object definitions that map into the persistent storage (database). I use a lot of JSF, and JSF does permit in many cases for domain model objects to be used as presentation MVC Model objects. Although most people overdo that and lose the benefits that can come when a true presentation model object can be used as a façade or decorator for domain model objects or other functionalities.

Since the persistent storage schema is relatively immutable, it often becomes the backbone of a set of objects which can then be overlaid by one or more sets of presentation objects. Or, for that matter, in JPA persistent objects sometimes serve as transfer objects when there's a relatively thick layer of business functionality between presentation and persistence.

All of which means that mostly it's a matter of what works best for your environment.

[Jimmy Clark]

In terms of "object-oriented software models", the term "domain" is typically used when describing applications creation for research, scientific or academic purposes, e.g. domain object model. The term "business" is typically used when describing applications created for commercial purposes, e.g. business object model.

When creating an application that includes a graphical user interface (GUI) for humans to interact with the application AND when implementing the Model-View-Controller (MVC) object-oriented design pattern, it is appropriate to maintain an independent business/domain model that does not contain any dependencies on whatever technology is used to implement the Controller or the View. There are many reasons for this. A close study of the MVC pattern will reveal these.

When implementing MVC properly, there will be a Presentation model which will be very similar to the "data" portions of the business/domain model. However, the "logic" in this model will be different, i.e. it will support the GUI and not contain business logic.

[Tim Holloway]

Jimmy Clark wrote:In terms of "object-oriented software models", the term "domain" is typically used when describing applications creation for research, scientific or academic purposes, e.g. domain object model. The term "business" is typically used when describing applications created for commercial purposes, e.g. business object model.

For better or worse, computer industry terminology tends to be somewhat fuzzy. Usually people are willing to make accommodations (After all, it's not like whether vi is superior to emacs!). So, for example "business logic" frequently refers to logic that's related to the core work done the application irrespective of the implementation technologies. So, for example, a video game can have "business logic" in it, despite having little to do with business in the conventional sense. Depending, of course, on who you ask, since opinions do vary. Personally, I'm not that thrilled with the term "Domain Object Model" since it's more of a statement than a description, but we have a general agreement on its meaning, so it will do until someone coins something better.

When implementing MVC properly, there will be a Presentation model which will be very similar to the "data" portions of the business/domain model. However, the "logic" in this model will be different, i.e. it will support the GUI and not contain business logic.

To be precise, this logic is usually in the domain of the Controller part of MVC.

And, although I reordered this last assertion to keep my own arguments together, the middle item is still noteworthy:

When creating an application that includes a graphical user interface (GUI) for humans to interact with the application AND when implementing the Model-View-Controller (MVC) object-oriented design pattern, it is appropriate to maintain an independent business/domain model that does not contain any dependencies on whatever technology is used to implement the Controller or the View. There are many reasons for this. A close study of the MVC pattern will reveal these.

Unless one is into pedantry for its own sake, the exact details of a methodology are relatively unimportant. What's more important is that there be a method (mutually agreed, validated and documented), since the whole point (outside of academics) is to make large, complex architectures easier to design and maintain. Maintaining independent domains - or as it's sometimes known - Separation of Concerns, is an important part of a good methodology. By reducing coupling between the various architectural layers, chances are minimized that a relatively small change in one place will avalanche into a major rewrite somewhere else.

[Don Kiddick]

In my case, the domain involves ui concepts. I think...

[Jimmy Clark]

Thanks for your comments Tim. I enjoyed reading them

[Ran Pleasant]

Don Kiddick wrote:I'm confused whether this is a domain model (where our domain is the ui) or a presentation model (in which case we don't really have a domain model).

Domain objects encapsulate data and behavior representive of the entities and processes of a business or other type of institution. Examples: Invoice, LineItem, LineItemDetail, Item, Order, OrderLine, Stock, Product, Person, Customer, Account, Sale, Warehouse, Door [of warehouse], Truck, Driver, Cargo, Route, Student, Grade, ClassRoom, Course, etc. If an object does not encapsulate a part of a business, etc., then it is not a domain object. Objects that encapsulate services or GUI components are not domain objects. Domain objects may or may not be directly stored in a database. Domain objects may or may not be the objects put into the models of a GUI page/form.

Most Web applications use what Martin Fowler refers to an Anemic Domain Model, in which domain objects encapsulate data but no behavior. This almost always results in applications that are basically procedural in nature. For example, in a true domain model an invoice object can calculate the total thus you'll see the method "invoice.getTotal()". But in an anemic domain model you will see the calculation in a service object, such as "invoiceSerivce.getInvoiceTotal(invoice)" or "invoiceSerivce.getInvoiceTotal(invoiceId)".

If you want to work with true domain objects [data and behaviors] you should learn Object-Oriented Analysis and Design (OOAD). For learning OOAD I highly suggest the book Applying UML and Patterns by Craig Larman.