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?
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.
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).
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.
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...
Related
Can someone briefly explain the difference between a Conceptual Class Diagram and a Detailed Class Diagram?
While a "Conceptual Class Diagram" expresses a conceptual (domain) model, it's not clear what you (or your professor) mean(s) with "Detailed Class Diagram": it could refer to a (language-/platform-independent) design model or to an implementation model like a C++ class model or a Java class model.
See also my answer to this related SO question.
The one-to-many relationships between conceptual models and design models, and between design models and implementation models are illustrated in the following Figure:
As an example that illustrates how the derivation chain from concept via design to implementation works, consider the following model of a people/Person concept/class:
Domain models are solution-independent descriptions of a problem domain produced in the analysis phase of a software engineering project. The term "conceptual model" is often used as a synonym of "domain model". A domain model may include both descriptions of the domain’s state structure (in conceptual information models) and descriptions of its processes (in conceptual process models). They are solution-independent, or ‘computation-independent’, in the sense that they are not concerned with making any system design choices or with other computational issues. Rather, they focus on the perspective and language of the subject matter experts for the domain under consideration.
In the design phase, first a platform-independent design model, as a general computational solution to the given software engineering problem, is developed on the basis of the domain model. The same domain model can potentially be used to produce a number of (even radically) different design models representing different design choices. Then, by taking into consideration a number of implementation issues ranging from architectural styles, nonfunctional quality criteria to be maximized (e.g., performance, adaptability) and target technology platforms, one or more platform-specific implementation models are derived from the design model.
A conceptual class diagram is used to understand and analyze a problem domain. A detailed class diagram is a design artifact, where many things may have been optimized away. For example, every dog might bark, but a dog-salon application doesn't care, so it can optimize away that fact.
I don't know of any standard or methodology that defines both these concepts. For example, the UML specification does not mention them. I think every answer will be subjective. I will give my own answer, based on more than 25 years of experience with IT-related modeling.
In a conceptual class diagram, every class is a concept, usually related to the business domain, the real world, e.g. Customer, Order etc. It may also show concepts that cannot be directly found in the business domain, but are needed to model the functionality of a particular application, e.g. BackupCopy. These are concepts the user of the application must understand. See also www.agilemodeling.com
There are other types of class diagram, e.g. class diagrams that model the source code, where every class corresponds to a Java class or a C# class, or class diagrams that model the physical database structure, where every class corresponds to a database table.
Each of these types of class diagrams may or may not be detailed. If a class diagram is not detailed, it typically does not show any attributes, or only the main attributes. If a class diagram is detailed, it shows all attributes relevant for the problem at hand and the data types of these attributes.
The concept of a conceptual class diagram is e.g. explained by Scott Ambler at http://www.agilemodeling.com/artifacts/classDiagram.htm#ConceptualClassDiagrams.
Basically "Conceptual" here means that the content of the diagram is taken from an analytic view point that takes the "concepts" of a domain and describes them.
For "concept" you could also say:
thing
item
aspect
object
topic
The conceptual diagram is basically what you get if you ask people for what problem they'd like to get solved by your software. So you analyze the situation/problem by asking questions that will help you create you diagram:
what are the things that are relevant? - these will be your candidates for classes
what are the features of those things? - these are the candidates for your attributes
how are the things releated to each other - e.g. is one part of another? Does it need the other? - these are the candidates for your relations
what should you be able to do with these things in your system ? - these are the candidates for your operations
In the past this step was called OOA - object oriented analysis. The steps following this are OOD - object oriented design and OOI - object oriented implementation. Many years ago some authors proposed to create three different models for OOA/OOD and OOI. Therefore you'd have different and usually more detailed diagrams for OOD and OOI. For the term "Detailed Class Diagram" i'd guess that one of the OOD and/or OOI views would be meant. Be careful though - some of the diagrams created this way will have patterns or pattern-like ideas as a basis. You'r diagrams would tend to be very repetitive and redundant if you keep capturing such patterns in concrete diagrams for every conceptual diagram. I'd rather recommend to give just one example of how to go from problem to solution and then comment "do it this way for all other concepts that are similar".
Can someone briefly explain the difference between a domain class diagram and a design class diagram?
I found a explanation on Yahoo answers,
but I find it quite confusing.
A domain model is called conceptual model in database modeling, while a design model is called logical model.
These distinctions are also used in model-driven development, where we have a succession of three types of models:
(solution-independent) domain models resulting from domain/requirements engineering in the system analysis, or inception, phase of a development project;
(platform-independent) design models resulting from the system design activities in the elaboration phase and typically based on a domain model;
(platform-specific) implementation models, which may be (e.g., JavaScript or Java EE) class models, SQL table models or other types of data models derived from an information design model.
While system modeling includes both information and process modeling, you seem to be concerned with information modeling only. Here, we can use the terms "domain class diagram" and "design class diagram" for the conceptual information model and the information design model made in the form of UML class diagrams.
The one-to-many relationships between conceptual models and design models, and between design models and implementation models are illustrated in the following Figure:
Considering information/class/data modeling we get the following picture:
As an example that illustrates how the derivation chain from concept via design to implementation works, consider the following model of a people/Person concept/class:
Domain models are solution-independent descriptions of a problem domain produced in the analysis phase of a software engineering project. The term "conceptual model" is often used as a synonym of "domain model". A domain model may include both descriptions of the domain’s state structure (in conceptual information models) and descriptions of its processes (in conceptual process models). They are solution-independent, or ‘computation-independent’, in the sense that they are not concerned with making any system design choices or with other computational issues. Rather, they focus on the perspective and language of the subject matter experts for the domain under consideration.
In the design phase, first a platform-independent design model, as a general computational solution to the given software engineering problem, is developed on the basis of the domain model. The same domain model can potentially be used to produce a number of (even radically) different design models representing different design choices. Then, by taking into consideration a number of implementation issues ranging from architectural styles, nonfunctional quality criteria to be maximized (e.g., performance, adaptability) and target technology platforms, one or more platform-specific implementation models are derived from the design model.
See also the Open Access book chapters Information Modeling and Deriving a Table Model from an Information Design Model.
If your focus is on the diagram itself, there are two big differences between diagrams about domain model and diagrams about design model: (At least this is what the Larman book Applying UML and Patterns says)
In UML diagrams which represent domain model, you cannot use arrows. All classes are interlinked with a line, which signifies "relation", and you should use text annotations over the lines to illustrate what relation it exactly is. While in design models, you have to use arrows, all types of arrows: association, inheritance... etc
In design model you have to specify the type of properties and methods etc, while in domain model you only have to write them without anything additional(just like in real world). For example, value: int in design model will be written as value in domain model.
Reference: Applying UML and Patterns 3rd Edition Chapter 9 and 16.
UML has NO such diagrams
Enterprise Architect has Domain Model - look at wiki.
As for "class design diagram", it is simply unknown neither by EA, or by VP UML, or UML itself. I think, the usual class diagram form the UML is meant.
I read about domain model and its importance and I have the following doubts :
What kind of problems can one resolve with domain models? in other words,for each problem I should build a domain model?
As far as I know, The domain models are represented using class diagrams .there is no difference between class diagram and domain model?
I also would like to understand In which way is vocabulary related to a domain model?
What kind of problems can one resolve with domain models?
Pretty much any problem that you want/need to provide a software solution for is amenable to modelling. In fact: however you do it, you must 'model' your problem domain in some way, shape or form. If you don't capture the rules and policies of the problem in software somehow it's pretty unlikely the end system will meet its intended requirements.
in other words,for each problem I should build a domain model?
It depends what you mean by 'build a domain model'. See above and below...
As far as I know, The domain models are represented using class diagrams .there is no difference between class diagram and domain model?
Class Diagrams are one way to model a domain. Actually, they're one way to model part of a domain. The primary advantage of a Class Diagram is that it exposes the relationships in the problem space explicitly and clearly. There is a body of opinion that says the semantics of a domain arise primarily through the relationships among concepts (classes) - more so than the classes themselves. If you buy into that opinion then it's possible/likely that you'll find a class diagram useful.
Note however that Class Diagrams only capture the structural elements of a domain: Classes, Attributes and Relationships. A CD doesn't capture behaviour. A Domain Model needs both structure and behaviour if it's to model the problem space in any useful way. So you'll need to augment the class diagram with some behavioural description; e.g. state models and/or actions.
There are other ways to model domains too. It can be a set of java/c# classes. The main disadvantage of such an approach is the reduced emphasis on relations. Unlike class diagrams, OO languages don't provide relations as first class constructs. The advantage is that programming language environments (editors/compilers/libraries/language runtimes) provide much better support for defining the behavioural aspects of a domain than most modelling tools.
More generally there's no rule that says a Domain Model has to follow the OO paradigm. It could be a set of functions and types in Haskell or OCAML. Or it could be some differential equations or other mathematical construct.
The key thing is that the model - however expressed - provides a description of the problem space. To be useful that description will not be complete - it will only capture the subset of properties in the problem space relevant to the system requirements. To be useful however it should be correct - the concepts and behaviour that are captured should accurately reflect the world being modelled.
I also would like to understand In which way is vocabulary related to a domain model?
You can think of a Domain Model as a way to produce a formalised and highly structured vocabulary. Actually, it captures some grammar too; e.g. it says that the participants in the 'Ownership' Relation must be a Dog and a Person; not two Dogs, or a Person and a Spoon.
This is what Eric Evans calls 'Ubiquitous Language' in Domain Driven Design. It means that the terminology used in the model should accurately reflect that of the problem being modelled. So if the real world domain experts use the words 'Person' and 'Dog', the model shouldn't use 'Homo Sapien' and 'Canine'. The rationale is simple: if developers (modellers) use the same terms as the domain experts, there's much less chance of misinterpretation. It also leads to more productive and pleasant conversations since everyone is using familiar words with a common meaning.
Summary
A Domain Model is an abstraction. It represents a subset of the concepts, rules and policies intrinsic to the real-world problem the system addresses.
A Class Diagram is one way to represent the structural aspects of a Domain Model. It does not capture the dynamic aspects. These are equally important.
There are other ways to model a domain. They are not limited to the Object-Oriented paradigm.
A Domain Model should be a structured vocabulary for the problem space. It should adopt the terminology used by experts in that field.
hth.
What is the difference between a domain model and a data model?
A datamodel is a design model that only describes data and it's relations. The model contains entities, but they are described in terms of what data they own not how they act on this data or what their responsibilities are.
An domain model on the other hand, is a conceptual model used in analysis of a problem domain. It describes the domain in terms of entities that have relations, data and behaviour. It describes the responsibilities of those entities as relevant for understanding the problem domain.
BTW an excelent and very short introduction to UML is:
UML Distilled: A Brief Guide to the Standard Object Modeling Language
A data model is focused on the DB schema definition, including tables, columns, and relationships.
A domain model is focused on the business domain, including concepts (classes of objects), behavior (methods/logic), and relationships.
In both cases, the cardinality is used for relationships (e.g. 1:1, 1:Many, 0:Many, ...).
That said, you would ideally like the data model and domain model to be closely related, i.e. a Person with name, ... and a MailingAddress, ... relates to a PERSON table with a NAME column and a FK to a MAILING_ADDR table entry. You have to decide where logic is hosted - in the objects in the software system vs. in the DB via procedures, triggers, and such.
I think it's important to provide some clarity here for posterity.
A data model is a design for how to structure and represent information. By structure, I mean concerns like "fifth normal form". By representation, I mean choosing a computer serialization, such as integer, floating point, or string.
The term domain model actually has two conflated meanings.
A model of essential characteristics of real or imaginary things in the world. In this kind of model, classes represent human conceptualizations and instances are things in the world. For example, a "Person" class would have instances including you and me, and an essential characteristic might be that every Person has a mother. This kind of model is often called an conceptual ontology or concept model and is intended to provide meaning.
A model of required information about things in the world, usually with some system in mind. In this kind of model, classes represent information that must be stored about things in the world. For example, a "Person" class would have instances representing required information about you and me, such as first name, last name, date of birth, current height, and current weight. This information often does not include all essential characteristics, such as our mothers, because, for the purposes of a particular system, that information is not required. This kind of model is often called an information model, conceptual data model, or operational ontology.
Both the UML and OWL languages can be used to represent either kind of domain model. Both can be considered analysis models, as they are used to analyze a domain. One is used to understand things in a domain, the other is used to gather requirements to build a particular software or database system for things in a domain. Both are necessary, and, unfortunately, they are usually conflated such that people building an analysis model are themselves confused about what they are modeling!
I think that domain model and data model are now pretty much the same with new top down modelling technologies. I mean that you can model in a class diagram and only add database stereotypes in your diagram. If you use the tool that I use then your ejb3 annotation would be immediately synchronized with your code. The next step is only to use a mapper to create your database. This technology only works with Java
I am quite new with DDD and would like to know about any pitfalls you might want to share. I will summarize it later for more newbies to read :)
Thanks
Summary so far:
Anemic domain model where your entities are primarily only data bearing and contain no business logic
Not using bounded contexts enough
Focusing too much on patterns
There is a good presentation on this topic as well here (video).
Probably the most important one: not grokking the central, fundamental principle of the Domain Model and its representation in Ubiquitous Language. With the plethora of technology options around, it's very easy for your head to fill up with ORMs, MVC frameworks, ajax, sql vs nosql, ... So much so there's little space left for the actual problem you're trying to solve.
And that's DDD's key message: don't. Instead, explicitly focus on the problem space first and foremost. Build a domain model shorn of architectural clutter that captures, exposes and communicates the domain.
Oh, and another one: thinking you need Domain Services for everything you can do in the domain model. No. You should always first try to put domain logic with the Entity/Value type it belongs to. You should only create domain services when you find functions that don't naturally belong with an E/V. Otherwise you end up with the anaemic domain model highlighted elsewhere.
hth.
One of the biggest pitfalls is that you end up with a so-called anemic model where your entities are primarily only data bearing and contain no business logic. This situation often arises when you build your domain model on top of an existing relational data model and just make each table in the database an entity in your domain model.
You might enjoy presentation of Greg Young about why DDD fails.
In short:
Lack of intent
Anemic Domain Model
DDD-Lite
Lack of isolation
Ubiquitous what?
Lack of refinement
Proxy Domain Expert (Business analyst)
Not using bounded contexts enough. It's toward the back of the the big blue book but Eric Evans has gone on record as saying that he believes that bounded contexts and ubiquitous language are THE most important concepts.
Similarly, people tend to focus too much on the patterns. Those aren't the meat of DDD.
Also, if you do not have a lot of access to domain experts you are probably not doing DDD, at best you are DDDish.
More concretely, if you end up with many-to-many relationships, you've probably designed something wrong and need to re-evaluate your aggregate roots/contexts
Only adding to what others have already said;
My personal experience is that people often end up with an anemic model and a single model instead of multiple context specific models.
Another problem is that many focus more on the infrastructure and patterns used in DDD.
Just because you have entities and repositoriesand are using (n)Hibernate it doesn't mean you are doing DDD.
It's not from my personal experience with subject, but it was mentioned for a couple of times in DDD books and it's what I've been thinking about recently: use Entities when you really need identity, in other cases use Value Object. I.e., Entity pattern often happens to be the default choice for any model noun, and it's not the way it should be.
Beware of the Big Ball of Mud.
One of the pitfalls of domain driven design is to introduce ambiguity into a model. As explained in the article Strategic Domain Driven Design with Context Mapping:
Ambiguity is the super-villain of our
Ubiquitous Language
This may happen when two distinct concepts share the same name, or when the same concept can have different uses. It may be necessary to
expose the domain structure in
terms of bounded contexts in a context
map
If a model is used in too many different ways, or has too many responsibilities, it may be a sign that it should be divided.