What's the difference between Data Modelling and Domain Modelling?

Question

By the way - with reference to data modelling I'm referring to logical or conceptual data models - not physical ones.

The question came up during a discussion at work; naturally I leapt to Wikipedia to get some basic definitions in place - hoping that they might clarify the difference - but they didn't...

A conceptual schema or conceptual data model is a map of concepts and their relationships.

Logical Data Modles seem very similar (from this definition):

A logical data model (LDM) in systems engineering is a representation of an organization's data, organized in terms entities and relationships and is independent of any particular data management technology.

Where-as...

A domain model, or Domain Object Model (DOM) in problem solving and software engineering can be thought of as a conceptual model of a system which describes the various entities involved in that system and their relationships.

The differences between domain model vs conceptual data model seems particularly murky.

One of the things which adds to this confusion is that (from what I've seen) a domain model is usually modelled using a UML class diagram - the class entity in a UML class diagram supports methods - our colleague maintains that a domain model must not contain "operations". I can understand domain modellers using a sub-set of a UML class diagram - but isn't it dangerous to assume people will refrain from including "operations" if the tooling they are using supports it?

Hydro

Answer 1

Good question, the problem is that it depends on the definion of the terms, I think they differ slightly based on the sources. I would agree with previous answer - domain models are for describing the problem domain, at least the part you need to develop a solution. You describe all the various entities, their relations and their behaviour. I think that this is also the view from the Domain Driven design perspective. Data models on the other hand are used for describing the data in your system and relations or associations between them. This is useful for describing what needs to be stored in the system and might also give hints how. I think data models would apply for your "no operations" rule, because they are not important in this respect.

Seed

I think we're all clear on what a data model is all about - for me the ambiguity is around the domain model: should it describe "operations"? If it only contained the relationships between entities - how is that different form a domain model? Is it just that a domain model captures more than data? – Hydro

Domain model is very different to a data model. As I said it describes also behaviour - operations. However they might be even different in design. Domain model captures the domain according to reality (bounded by the context of the system which will implement that domain model). On the other hand, the data model should be optimized for data storage and retrieval, which might result in abstractions without correspondence to reality. I recommend you read more on domain model in context of Domain Driven Design, for example here: infoq.com/minibooks/domain-driven-design-quickly – Poppy

Answer 2

Domain Modeling (in the sense of Domain Driven Design) is all about modelling the behavior of the domain concepts, while Data Modeling focuses mainly on... data.

It doesn't mean that Domain Modeling ignores data structures. It just puts more emphasis on operations and how they can be uses to solve problems.

I don't know much about other than Domain Driven Design domain modelling techniques, but DDD involves (apart from modeling data and behavior) also explicit modelling of consistency boundaries (aggregates).

Malleus

Yes that's what I thought too, so I'm assuming my colleague's position on keeping operations out (of the domain model) is flawed (?) - at least from a DDD perspective. – Hydro

@AdrianK Yes, from a ddd perspective this is an anti-pattern called anemic model. – Artichoke

@AdrianK I'm still reading Applying UML and Patterns but Larman also keeps operations out of the domain model on purpose, and later adds operations to a diagram that is based on the domain model (both are class diagrams). And I'm sure the book does not advocate anemic models. – Arcature

Answer 3

This is an old thread, but here's a slightly improved answer to clarify some of the others posted here.

The concept of 'domain' (and other kinds of models such as conceptual, logical and physical) is orthogonal to the technique used to represent the model (eg. ERD, UML etc). A domain model is essentially the same as a conceptual model, but different design methodologies might have slightly different terms and definitions. While it's common to draw domain models using UML or ERD to describe entities and their relationships (or classes/methods in UML), this only applies to modelling the information to be managed by a system - logically, the concept of domain modelling (or conceptual modelling, logical modelling or physical modelling, etc) can apply to any problem situation and a solution. Depending on the nature of the problem and the problem solving approach, other modelling techniques could be used to achieve the same goal.

In short, domain modelling and conceptual modelling are essentially the same thing, hair-splitting definitions aside. The concept applies to what the modeller is trying to communicate. The concept of data modelling (ie. ERD) or object-oriented modelling (ie. UML) refers to how the modeller communicates it.

Phobia

Answer 4

I would say that a domain model describes the problems (what we want to manage/solve) on a given domain. The data model would describe the solution (how we're going to solve it) to the problem described on the domain model.

However, we are indeed in murky waters...

Gavette

I assume when you say "the data model would describe the solution" that you just mean from the data perspective - yes? – Hydro

@Adrian Yes. Data store and data flow. – Gavette