• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Domain object model

 
Ranch Hand
Posts: 594
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
in domain object model,object should contain data only or data and behavior.
I checked a project code ,it has some DOM (domain object model),it has only data.

What are the difference between architecture and design pattern
 
Ranch Hand
Posts: 237
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi

A domain model as per definition can have both state & behavior or either of them.
 
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It could have both behavior and data or only data, it depends on different design style, and different situations.

But in most cases, both containing behavior and data should be the preference.

Please take a look at "Business Object" pattern section in book "Core J2EE Patterns" (Sun)

Peace,
Tao
 
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Though you can have both data and behavior in object model the behavior should be limited to data processing and not include behavior related to business processing.
 
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Sreeni Jamakayala:
Though you can have both data and behavior in object model the behavior should be limited to data processing and not include behavior related to business processing.



Why not? If we have only data processing, should we call it "data" model?
"Domain" has many meaning more than just data.


I recommend to include behaviors in domain model.
 
Sreeni Jamakayala
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Business processing related behavior can be captured in class diagrams and implemented, for example, using servlets (web tier) or using Business Object pattern (business tier).
 
Lann Lu
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Business object is your domain object essentially. Your domain objects are NOT dumb value holders, or DTO, or value object etc.

Domain objects normally are persistent, and have rich behaviors.

Most business logic scatters around service objects and business/domain objects. It is hard to draw a line. If the logic is close to your domain, then put it domain objects; if you feel the logic is hard to fit to domain object, then it is indicating that you may have to put the logic to service object.
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Sreeni Jamakayala:
Business processing related behavior can be captured in class diagrams and implemented, for example, using servlets (web tier) or using Business Object pattern (business tier).



Classes can have methods that relate to "domain" and not relate to.

Behaviors that relate to "domain" should be put in "domain" model.
 
Sreeni Jamakayala
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks, that helps. My understanding is that the domain objects represent entities/data and contains behavior that is generally related to persistence/data processing.

As per Business Objects, I read somewhere that you try to seperate out the concerns of persistence related processing from Business Objects.
 
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
business and domain mean the same thing.

The term "business" is typically used in commercial environments.

The term "domain" is typically used in academic or research environments.

business/domain classes represent a combination of data and processing logic related to business/domain requirements.

As per Business Objects, I read somewhere that you try to seperate out the concerns of persistence related processing from Business Objects.



To help you understand this, note that code associated with storing data in a database is not considered business/domain logic. This is considered persistence logic. Examples of this type of logic are JNDI lookups, JDBC classes and SQL statements, Hibernate mappings and class behaviors, etc.

An example of business/domain logic would be checking a customer's order history and applying a 25% discount to their current order if they meet a defined criteria and their name starts with the letter X.
 
Sreeni Jamakayala
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Kengkaj, Lenn, James,

Thank you for correcting me. I have been thinking domain and business are slightly different where in Domain objects are one step closer to data related and Business objects are one step closer to business related processing. Otherwise I am cool with differences between persistence logic vs. business logic.

These discussions help me learn better everyday. Thank you.

-Sreeni
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by James Clark:
business and domain mean the same thing.

The term "business" is typically used in commercial environments.

The term "domain" is typically used in academic or research environments.

business/domain classes represent a combination of data and processing logic related to business/domain requirements.



For clarification, business model is quite another story, it's about ... "business", read Wikipedia for more information http://en.wikipedia.org/wiki/Business_model

I cannot explain it clearly, because I'm not a business modeling expert, but domain model and business model are not the same, actually they are very different .
[ November 05, 2008: Message edited by: Kengkaj Sathianpantarit ]
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My reference to the term "business model" is in regards to object-oriented software engineering.

There may be other uses and interpretations of the term outside the scope of OO software development.

P.S. "business model" in terms of this discussion is a shortcut for the term "business object model"
[ November 06, 2008: Message edited by: James Clark ]
 
Sreeni Jamakayala
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here is some info from the book <b>EJB 3 in Action by Debu Panda, Reza Rahman, Derek Lane</b>.

Domain model is a conceptual image of the problem your system is trying to solve. Literally, it is made up of the objects in the "system universe" and the relationships or associations between them. An object in a domain model need not be a physical object but just a concept used by your system. Domain model describes the objects and how the objects might relate to one another, but not how a system acts on the objects.

Think Domain model as a set of interlocking toy blocks. Each uniquely shaped block in the set is an object. The shape of each block determines how they fit with one another. Each such "fit" is a relationship. In the end, though, you put together the blocks into whatever configuration sparks your imagination. The master plan for putting together the final results forms the business rules of the application. The business rules are implemented by the session beans and MDBs, while the persistence API implements the domain model that the business rules act on.

Domain models are eventually persisted into the database. Domain objects contain attributes (mapping to database table columns) but no behavior. This type of model is referred to as the <b>anemic domain model</b>. A <b>rich domain model</b>, on the other hand, encapsulates both object attributes and behavior and utilizes objected-oriented design such as inheritance, polymorphism, and encapsulation.

An anemic domain model may not necessarily be a bad thing for some applications. For one thing, it is painless to map objects to the database. As a rule of thumb, the richer the domain model is, the harder it is to map it to the database, particularly while using inheritance.

Hope that helps.
-Sreeni
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The term "domain model" is a shortcut for the complete term "domain object model."

domain model = domain object model = business model = business object model
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by James Clark:
The term "domain model" is a shortcut for the complete term "domain object model."

domain model = domain object model = business model = business object model


I don't agree, domain model is not business model.

Please read wikipedia, it's very different.

About "business object", did you mean Business Object pattern in J2EE patterns?

Beware, in Core J2EE patterns, it says that in non-commercial system, we can call "Business Object" as "Domain Object".

But it doesn't talking about "business model" and "domain model".

I don't sure about "domain object model" and "business object model", why they were call "object"? Actually, things in that models are conceptual classes.

When I have time, I'll discuss about this in more detail.
[ November 06, 2008: Message edited by: Kengkaj Sathianpantarit ]
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The text in wikipedia for "business model" is not in the context of object-oriented software engineering.

There are mutliple uses of the term in specific contexts, as I mentioned earlier. An understanding of which "use" depends upon the context. This forum is not a business development forum, it is about software development. Therefore, what is currently in wikipedia does not apply to the context of our discussion.

The distinction between object and class is not really significant.

Below is a great book for further study on business/domain objects and how to effectively design object models.

Object Technology: A Manager's Guide
Publisher: Addison-Wesley Professional
Language: English
ISBN-10: 0201309947
ISBN-13: 978-0201309942
[ November 07, 2008: Message edited by: James Clark ]
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks James, I'll read the book you suggested when I have time.

Anyway, I still don't agree to use term "business model", it's a very well known term which is not directly relate to software modeling.
 
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Kengkaj Sathianpantarit:

I don't agree, domain model is not business model.



Both terms mean one and the same.
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Darya Akbari:


Both terms mean one and the same.



If you say so, can you provide authorize resources to support your claim?

I'll say again, please read wikipedia, as well-known terms they are VERY different.

I believe when most people say "business model", they don't mean "domain model" for sure.

I have another question, is "business patterns" the same as "domain patterns"?

http://en.wikipedia.org/wiki/Domain_model
http://en.wikipedia.org/wiki/Business_model
[ November 13, 2008: Message edited by: Kengkaj Sathianpantarit ]
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
(See post above with date: Friday, November 07, 2008 10:10 AM)
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry, James. But your post just stated a book.

Could you please to quote text in that book which states that business model is domain model?

Because I already provide evidence from Wikipedia that they are VERY different, if you want to argue in this topic, you do need to provide more solid supporting evidence, not just a book name, at least please quote text from the book.

Thanks.
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Kengkaj,

I'll give you a third term which you will probably disagree : Object Model

They all mean one and the same. This is because different authors use different names for the same thing, the domain model . I agree its confusing but this how the world is.

Why do you stick so much to Wikipedia? Any idiot there can post whatever he wants.
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Kengkaj Sathianpantarit:
Because I already provide evidence from Wikipedia that they are VERY different, if you want to argue in this topic, you do need to provide more solid supporting evidence, not just a book name, at least please quote text from the book.



Do you think because you quote Wikipedia you are right ? Why can't you accept the fact that different authors use different wording for one and the same thing?
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Kengkaj Sathianpantarit:
I don't sure about "domain object model" and "business object model", why they were call "object"? Actually, things in that models are conceptual classes.



Kengkaj,

This is your real problem . Why do we call them object model?

This is done by intention. Objects, some call them business objects others call them domain objects, are tangible real world things who exists in a problem domain.

Once you understand how in a problem domain all your domain objects are related to each other you can start to pin them down into your UML tool.

Modelling is not about abstract things. You model concrete tangible things which we call objects. Don't confuse it with the Java definition of an object. In modelling we use the term object in sense of tangible things.

Hope that helps,
Darya
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It looks like there is either a limited understanding of the meaning of the term "context" or an obsession with "wikipedia web pages" as a source of information.

An good example of "context" is found in the acronym EAR. This acronym has many definitions which are not related. So, "context" refers to the subject matter associated with its use. EAR may mean a file format of Java programming, or EAR may mean Export Administration Regulations, or EAR may mean European Agency for Reconstruction.

The term "business model" also has multiple definitions and the context of its usage indicates which one should be interpreted/applied.

At this point, it is a silly point to discuss further.

Good luck!
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by James Clark:

At this point, it is a silly point to discuss further.

Good luck!



Isn't that a bit harsh ?
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Not intended. Sorry that you read it that way.
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agreed that no point to discuss further, because it seems that you don't want to provide supporting evidence.

So I assume that Object Technology: A Manager's Guide doesn't state that "domain model" is "business model".

If you have time, try to read Business Modeling with UML : Business Patterns at Work book.

OK, end of discussion.
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Kengkaj,

I did not end the discussion . So if you like, keep the discussion on with me.

First of all James is right, if you like it or not. I also gave you an explanation that should have made it very clear to you why we have multiple names for it.

I also analyzed where your problem is (think object) and explained it to you .
 
Ranch Hand
Posts: 187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This was a good discussion. Thanks to James, Kengkaj and Darya.
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You're welcome
 
Ranch Hand
Posts: 271
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Kengkaj Sathianpantarit:



I'll say again, please read wikipedia, as well-known terms they are VERY different.



Sorry I couldn't resist , but what James is trying to tell you is that the wikipedia definition/explanation does NOT relate to OO software engineering(OOSE)..i.e the CONTEXT of that definition is has no relation with OOSE.Clearly , Wikipedia says :

A business model is a term used to describe a profit-producing system that has an important degree of independence from the other systems within an enterprise. The term is widely used for a broad range of informal and formal descriptions of the purpose, offerings, strategies, infrastructure, organizational structures, trading practices, and operational processes and policies.



Now to me that's a business definition and has not bearing at all to OOSE.As a matter of fact ,Wikipedia does differentiate between Business Model(http://en.wikipedia.org/wiki/Business_model) and Business Object Model (http://en.wikipedia.org/wiki/Business_Object_Model).

Suffice it to say that in the CONTEXT of object oriented software engineering , I think we all agree that business model is just short for business object model , and that's what James is saying.
 
reply
    Bookmark Topic Watch Topic
  • New Topic