Presentation Model vs Domain Model vs Data Model

[Mike Brown]

Just got back from giving a presentation on Domain-Driven Design (went great, got phenomenal feedback and sparked about an hour of conversation afterwards). While I was creating the presentation, I got to thinking about how the domain model and entity model don't necessarily coincide. The entity model should be more concerned with persistence while the domain model should encapsulate your business logic. It made me think about presentation. We all agree that your business objects shouldn't be concerned with presentation. I therefore propose that the presentation model COULD (I'll refrain from saying should at this point) be a separate model from your domain model. There might be some common structures between your three models (and should be represented as such) but your presentation model should only be concerned with those aspects of the domain model that need to presented to the user (or retrieved from them) to achieve the task at hand. I'm still building up this argument, but I wanted to get my thoughts out to you guys to see what you think about it. Any thoughts, concerns, or objections to my logic?

 

--Mike

[Josh Smith]

I absolutely agree.  Domain objects travel over the wire, are used by potentially different systems, and have domain logic in them.  Presentation objects adapt Domain objects in such a way that they are friendlier to a specific UI technology, typically for a specific application.  With that said, there is inevitably going to be some overlap.  Presentation objects must re-expose the state in Domain objects that is to be displayed (i.e. duplicated property declarations), have a way to hook up the Domain object validation logic with something the UI can display (i.e. potentially duplicated IDataErrorInfo implementations), and also raising property change notifications that are, or should be, raised by Domain objects.  Naturally, most of the duplication is simply a matter of delegating from the Presentation objects into the corresponding members of the Domain objects, so functional duplication between the two layers is typically at a minimum.

Josh

[Pavan Podila]

Mike,
         I would agree with your opinion on different data models for the business and presentation, although not too different. There will certainly be overlap. I remember long time back about a concept called "Data Model Continuum", which is the notion of progressive change of a data-model as you move from Storage to Presentation. I am not too sure if that is the right phrase to use but I do recall something along those line.<Need to google that up>

From my recollection, the continuum talks about the representation of data changes as we go from lower levels towards the higher presentation levels. The most analogous idea to this is the network stack, that starts at the physical layer and proceeds towards the application layer. Clearly the data models are different at each level. The frame of reference, terminology and logical connection of data-structures are different at each level. NO singular model can encompass all these data-structures and they have to be broken up into logical boundaries.

In our case too something similar is being done: Model, ViewModel, View. Each could again be broken into sub-logical boundaries. For example the Model layer can be broken into Business model, Database model (entity model), etc. The View and ViewModel can also encompass the Designer model, a data-model for representing UI components and their design criteria, and so on.

I am sure I have barely scratched the surface in explaining the continuum. Hopefully google can give more authoritative answers.


- Pavan -

On Thu, Sep 18, 2008 at 10:19 PM, Mike Brown <mbro...@gmail.com> wrote:

Just got back from giving a presentation on Domain-Driven Design (went great, got phenomenal feedback and sparked about an hour of conversation afterwards). While I was creating the presentation, I got to thinking about how the domain model and entity model don't necessarily coincide. The entity model should be more concerned with persistence while the domain model should encapsulate your business logic. It made me think about presentation. We all agree that your business objects shouldn't be concerned with presentation. I therefore propose that the presentation model COULD (I'll refrain from saying should at this point) be a separate model from your domain model. There might be some common structures between your three models (and should be represented as such) but your presentation model should only be concerned with those aspects of the domain model that need to presented to the user (or retrieved from them) to achieve the task at hand. I'm still building up this argument, but I wanted to get my thoughts out to you guys to see what you think about it. Any thoughts, concerns, or objections to my logic?

 

--Mike

--
the approach, rather than the solution
...o0O0o...
http://blog.pixelingene.com

[Mike Brown]

Okay, now that I've got at least two people who don't think I belong in a white jacket and padded room (at least on this topic) let's try to solidify the concepts.

 

What if we represented the data that travels between the different models as structs rather than full classes? Since structs are value objects, they would act as Momentos (or DTOs pick your poison) for the different model objects and more or less be the lingua franca between the models. This would also guarantee that the Model Objects can't be ACCIDENTALLY modified by a different layer. So if I want to update the Address on a Customer object, I would call customer.UpdateAddress(addressMomento) on my Customer business object rather than

customer.Address=newAddress;

customer.Save();

 

The differences here go beyond the fact that addressMomento is a struct while newAddress is a class. We are revealing the Intent of the interface, while also ensuring that the Customer is responsible for its state. The call to UpdateAddress would probably occur within a Command. What do you think so far?

 

 

 

 

[Corrado Cavalli]

I’m 100% with Josh opinion.

 

Corrado

[Corrado Cavalli]

I frankly missed you on this, but it sounds a little bit complicated, while I love using viewmodels on the UI side, I also love being able to use what technologies like LINQ/EF offer me (I mean customer.Address=”foo”; datacontext.SubmitChanges())

 

Corrado

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Mike Brown
Sent: venerdì 19 settembre 2008 06:19
To: wpf-di...@googlegroups.com
Subject: [WPF Disciples] Re: Presentation Model vs Domain Model vs Data Model

 

Okay, now that I've got at least two people who don't think I belong in a white jacket and padded room (at least on this topic) let's try to solidify the concepts.

[Mike Brown]

At that point you have one piece of code that knows about your business objects AND your persistence layer. So when the details of your persistence changes, your business object and the client of your business object has to change.

[Josh Smith]

I don't see a significant difference between the two approaches you showed.  I think a meaningful assessment of which style is preferable must be based on the context in which the design is implemented, and the personal preferences of the team.

Josh

[Mike Brown]

The difference is that the application layer shouldn't care that updating a customer address involves changing an address property and a call to save. Because what happens when updating a customer address involves changing the property, complex validation, verification of the address against a ip-geolocator, and posting the change to a message queue? The whole point of Object-Oriented Design is to encapsulate these concerns...I think at some point we as an industry forgot this basic concept we learned in Comp Sci 101.

[Bill Kempf]

Yes, the presentation model could be, and SHOULD be separate from your domain model.  That's actually why the M-V-VM has two models in the name of the pattern.  It also makes some sense to apply the same design pattern to separate the domain model from a persistence model, which I think is the basics of what you're proposing, correct?

However, I do not like the idea of customer.UpdateAddress(addressMemento), if I'm inferring what this does correctly by the comparison to "custmer.Address=address; customer.Save()".  If you make multiple changes to customer, you should not be persisting between each change, and an interface design that forces you to is badly designed, I think.  Which, when you carry out that thought to its conclusion, probably means separating the persistence from the domain model isn't such a great idea... at least at the interface level (I can see other reasons, such as services and dependency injection).

On Fri, Sep 19, 2008 at 12:18 AM, Mike Brown <mbro...@gmail.com> wrote:

--
Quidquid latine dictum sit, altum sonatur.
- Whatever is said in Latin sounds profound.

War is peace. Freedom is slavery. Bugs are features.

[Mike Brown]

I knew I was missing something. Yes there should be some way to signal to your domain object that you're finished making changes. I guess that could be the purpose of the Save function. So now our interface would be more like

 

Customer.UpdateAddress(addressMomento);

Customer.CreatePurchase(purchaseMomento);

Customer.Save();

[Josh Smith]

How does this:

customer.Address=newAddress;
customer.CreatePurchase(purchaseInfo);

customer.Save();

differ from the newly proposed technique of:

Customer.UpdateAddress(addressMomento);

Customer.CreatePurchase(purchaseMomento);

Customer.Save();

?

[Mike Brown]

Tell me why in the first example you didn't say

customer.Purchases.Add(newPurchase);

 

I think if you see the difference there you can follow the trail to why I don't think exposing the internal state of the business object should be done.

 

It's one of the principles of the rich domain model, reveal your intent through your interface. By exposing the Customer.Address property (assuming the property is a class Address and not a struct Address, you're giving someone the (pardon the expression) address to your Customer's internal data. At that point, it can be passed around and manipulated by someone ten hops away from your customer object.

 

Whereas by explicitly requiring changes to the Customer's Address to go through the UpdateCustomer function, we know EXACTLY where the change to our address is happening. And we can see our direct callers with two clicks.

[Josh Smith]

That's true, and a good point.  Though, relating this back to the original topic of the thread, I don't think that concerns like this affect whether the Domain objects and Presentation objects should be two separate layers.  The choice of how to move data around the system, and how to expose it on the various layers of objects, though important, is secondary to the larger question of: what layers would your design benefit from using?  My personal preference is to keep things simple, so if the app is small and has no need to segregate the domain objects from presentation objects, then I'm perfectly content with using V-VM (no leading M!).  Larger apps merit larger designs, so breaking them apart into multiple layers is best.

Josh

[Bill Kempf]

I personally can't agree with the V-VM comment.  Your domain model has no business exposing concepts like selection, for instance.  Keeping things simple to me generally means your VM may directly expose the M rather than wrapping it in a facade.

[Josh Smith]

If I'm building a simple utility app that has small amounts of data, no validation logic, no business rules, etc. why should I bother creating a separate set of classes just to store those values?

[Bill Kempf]

I understand the pragmatism, but by the same logic I can ask why you need to have a VM at all for such a small utility app?  Why not use the codebehind?  I'm not sure there's a point at which an app is large enough to need the benefits of automated testing, but small enough to not need the benefits of having a domain model entirely decoupled from the presentation.

BTW, I don't buy the "no business rules" at all.  If there's no business rules, there's not really an app, is there?  The app is *doing* something, isn't it?  And I also think it's going to be rare that you don't have any validation.  Even the lowly DIR command has to validate the input.

[Mike Brown]

One of my primary points in my presentation was determining when a rich domain model was merited. If we are developing iteratively (we are developing iteratively right?) it will become obvious when our apps will benefit from a rich domain, it will also become obvious when it becomes necessary to separate your presentation model from the domain model. I call it context sensitive architecture. For instance, in the current version of my pet project, I have NO layers. There is no model, I'm using event handlers instead of commands. It's HORRIBLE as an example of the patterns we talk about. However, it does what it needs to do at this point. When I go to the next iteration, I'll probably refactor what needs to be in order to get the needed functionality in that version.

 

I don't have a default architecture. If the customer wants a ranch, why would I design a bungalow for them?

[Josh Smith]

Bill - When building a simple little app, I always assume that later on I'll want to add more features later on.  So, I create a ViewModel, but "merge" the Model right into it.  If later on down the road, I need to add more features, I already have a well designed structure in place.  If the app were to grow even more, and become more complicated, I can always refactor it into using MVVM proper (i.e. add a Model layer).

I think one key distinction that you either ignored or overlooked is the difference between business logic and application logic.  Business logic (domain logic) is not the same thing as application logic.  Business logic involves applying a set of rules that exist "external" to the application itself.  Application logic is what makes the app do what it's supposed to do, such as firing off some business rules to be processed, showing a wait cursor, hiding/showing a panel, showing a MessageBox, etc.  Application logic belongs in the ViewModel, while Business logic belongs in the Model.  At least, that's how I see it.

Josh

[Bill Kempf]

I can just as easily factor stuff out of the codebehind as I can out of a VM.

As for the Application logic vs. Business logic, no, I don't think I overlooked that.  Can you honestly describe any application that would have application logic but not business logic?  I can't (well, maybe something like Baby Smash could fit that sort of description, though I'm not convinced even there).  Like I said, even the lowly DIR command has both.

* Application logic for DIR - accept arguments via the command line and provide results via the console.

* Business logic for DIR - validate that the directory exists (as well as that any other inputs are sane), then retrieve information about the directory.

I'll agree that this is probably a personal preference kind of thing, but for *ME*, I can't imagine a scenario where I felt an application warranted a design where I'd separate out into a view and a poo but not include a model.  Once I decided it was complex enough to warrant the poo, I'd want the model as well.