Basic terminology question - Business Logic, Domain Logic and Domain Model

[eliatlas]

I am reading the "ActionScript Developer's Guide to PureMVC" right now, and also trying to get some help in the Best Practices document and this great forum.
At this point, I start to realize, that in order to truly understand PureMVC, there are number of key terms that are needed to be figured out.
The problem is that I'm not sure there is a precise definition for some of them(at least not in the context of PureMVC).
For example, what is the accurate definition of Domain Model? This term is being used in both documents.
Is Domain Model similar to Model from PureMVC?
Also, I think that I understand the difference between Business Logic and Domain Logic, but how are they connected to Domain Model?
The best practices document says:

Commands house the Business Logic of our application; the technical implementation of the use cases our application is expected to carry out against the Domain Model. This involves coordination of the Model and View states.

but the next paragraph says:

The Model maintains its integrity through the use of Proxies, which house Domain Logic, and expose an API for manipulation of Data Objects.

So I am confused, Business Logic represents the use cases, which are the Domain Model. But why Domain Logic is not related to Domain Model?

[puremvc]

Since you have a copy of the book, you can see a definition of Domain Model, in Chapter 1 Introduction / Actors at the Boundaries / Use a Proxy as a Data Source for your Application:

"The unique cloud of relevant terms surrounding your application's real-world problems domain is generally referred to as the Domain Model"

In the app in the book, a fiction writing tool, the Domain Model includes terms like Series, Story, Part, Chapter, Scene, Draft, etc. These are the terms that we will attempt to represent in the data that the application will work with. They are implemented as Value Objects, data carrier classes that allow us to represent these terms with the various properties and relationships that come with them.

For the difference between Business and Domain Logic, see Chapter 7 Applying Business Logic. The first section is entitled Two Shades of Logic and explains this in some detail, including why there is a distinction.

In short:
Business logic = code that is interested in the use cases of your specific application
Domain logic = code that is interested in maintaining data integrity

The app in the book, again a fiction writing tool, has logic that makes sure that when you are editing a Story, and you select a Chapter in the timeline component that the other Chapters are closed and the one you selected is opened visually and selected. This is BUSINESS LOGIC. It fulfills the aims of this particular application.

The app also makes sure that when you create a StoryVO, it comes populated with the proper defaults for its type, (e.g., a new 'complex' StoryVO has one PartVO, which in turn has one ChapterVO, which in turn has one SceneVO, and so on). This is DOMAIN LOGIC. It maintains the integrity of the data.

Now, you may say, why is there a distinction? The "aims of my application" also include making sure the data is kept properly. So why wouldn't this so called Domain Logic just be considered another aim of my app?

The reason is that increasingly, it is the case that the classes used to represent, persist, and retrieve the domain model data need to be reused in more than one application. My current client has a web-based Flex media creation app and when they started it they had no intention whatsoever of creating another app with any of the classes. But then they wanted people to be able to share some of the created stuff,  but the app was too huge for a causal viewer to wait for downloading, so we reused the model classes in a lightweight Flex viewer app. Then a client of theirs wanted offline behaviors, so we reused the model again to create a desktop viewer with AIR. Then another of their clients wanted an iPad version of the app, so we had to create a Flex Mobile version, reusing the model classes of course.

The point is, it is important to separate the domain model classes from the particular application they are serving at the moment. The way you make this separation is by making a distinction between Domain Logic and Business Logic and not muddling the two.

-=Cliff>

[eliatlas]

Thanks Cliff

First of all, I would like to know who is your client so I could play with the application
Second, as always you answer is great, thanks!

[puremvc]

I would like to know who is your client so I could play with the application

I'd love to share, but unfortunately it's not a general consumer app, it's an enterprise app usable only by their corporate clients like HBO, Bravo, USA, and the like to create their major presentations.

Second, as always you answer is great, thanks!

As always, you're welcome anytime!

Cheers,
-=Cliff>