I'm really new to DDD and trying to grasp some of the concepts.
Could someone explain me the idea behind Domain Modeling in DDD.
I have already gone through wikipedia explanation: http://en.wikipedia.org/wiki/Domain_model but still seems like there are some gray areas in my understanding.
Based on what I understood, domain modeling involves building a model around the business entities to express their relationships, express the entities that participate in the model etc..
Isn't this something that has been in practice always? in Object Oriented world, you model business entities into classes, objects etc.. and build the software around this.
What I do not understand is the emphasis Domain Modeling gets in DDD. Is it the same object/class modeling that you find in OO world, or is this something new to DDD ?
How does it differ from Object Oriented design/modeling?
Your answers are highly appreciated.
One distinction is that a "proper" implementation of the Domain Model Pattern in DDD is isolated from cross-cutting concerns.
For example, it contains nothing to do with databases or other persistence. Where it contains validation logic, it is business validation, not "does the name exceed the column length?" validation.
The idea is that the domain model encapsulates "the business" -- in business terms ("ubiquitous language"), to the extent possible -- and exposes relevant aspects of the business to "the program" without acquiescing to the needs of the software.
On the flip side, "the software" is concerned with IO, UI, and the like, but delegates all business logic to the domain model.
In principle, you can wrap your domain model up in an assembly and use it across multiple applications. When business rules change, as they do, you have one very logical place in which to affect the changes (because the model is a 1:1 or nearly-so representation of the relevant aspects of the business and is described in the same terms as the business).
The Domain in DDD does not need to be implemented in OO. In my experience an OO domain model is usually best, but there are very valid examples of situations in which it may not be.
You might implement a domain in rules, with a rule engine (example in The Netherlands where this is done for a large mortgage application). Or you might do it in a functional language. The essence is that your domain, in however fashion it is implemented, is isolated from what I usually call the technical aspects of your application (or, as the previous answer calls it, cross-cutting concerns, although I think there may very well be cross-cutting concerns within a domain). An isolating layer, which may be implemented using adapters, makes the domain as much as possible, even completely, independent from the technicalities. This layer usually leverages patterns such as Facade and Observer.
Related
Consider certain kinds of objects involved Domain-Driven Design (DDD): Entities, Value Objects, Domain Events, and Domain Services.
Which of these are considered to be Domain Objects? And are there other names for abstractions that encapsulate a subset of those?
I can identify various abstractions that are useful to have when talking about DDD or domain models:
Entities and Value Objects. I often find myself mentioning "Entities or Value Objects". Most notably, these are the ones that model the domain's state. In contrast, Domain Services are stateless, and I would argue that Domain Events merely reflect information about how the domain came to be in its current state.
Entities, Value Objects, and Domain Events. These may all contain or represent data, whereas the Domain Services only define behavior.
All objects recognized by the domain model. It is useful to be able to talk about parts of the domain model in general, as opposed to concepts outside of it.
It's interesting how even Stack Overflow's domain-object tag has a confusing definition:
Domain Objects are objects made for dealing with the domain logic at the Model layer. These objects generally simulate real (or virtual) items from real-life: Person, Post, Document, etc.
The initial definition, focused on "dealing with the domain logic", leans towards "all objects recognized by the domain model". The examples then lean towards "Entities and Value Objects".
DDD hammers on a clearly defined, unambiguous Ubiquitous Language, and with good reason. Shouldn't it lead by example? :)
Which of these are considered to be Domain Objects?
All of them. They are "objects" that implement our domain model. In the original DDD text, Eric Evans also used the phrase "model elements".
The distinctions between them are largely a consequence of the constraints of the Java language. You wouldn't need "value objects" if you could just create bespoke values; you wouldn't need "domain services" if you could just pass around the capabilities you need. You wouldn't need "domain events" if you have "messaging" as a ubiquitous construct, and so on.
DDD hammers on a clearly defined, unambiguous Ubiquitous Language, and with good reason. Shouldn't it lead by example? :)
Well, part of the riddle is that these patterns are part of a general purpose language, and one of the central messages of DDD is that you shouldn't allow general purpose concerns to distract you from the domain itself.
That said... yeah - it would be better today if Evans had a rich understanding of these ideas eighteen years ago, and was able to introduce the best language and provide counter measures to prevent semantic diffusion.
I am getting more into understanding Domain Driven Design and a bit confused about how Naked Objects Pattern and Onion Architecture could relate to each other?
Individually how they relate to DDD is quite clear, but is it also possible to relate them with each other?
(Declaration of interest: I was the author of the Naked Objects architectural pattern, and manage the Naked Objects Framework - NOF.)
I do not profess to know the Onion architecture well, but at one level the ideas seem compatible with Naked Objects; at another level it is comparing apples to oranges.
The Onion Architecture is a set of design principles that you could apply when building an architecture from scratch using various technologies and patterns. In theory, so is Naked Objects; in practice you would only adopt the Naked Objects pattern by building your systems using a framework that implemented it - it is too much like hard work to write your own. The Naked Objects Framework is the largest, and purest, such framework, but not the only one.
So the meaningful comparison is not between the Onion principles and the NO principles, but between the former and a specific implementation of the NO principles. I'll, obviously, use the NOF as the example.
NOF very strongly implements and enforces the principles that Onion is derived from: very strong separation of concerns. The domain model is almost completely independent of the infrastructure: the sole point of contact is via a single, very lightweight, interface (IDomainObjectContainer), which defines a service, an implementation of which is automatically injected into any domain entity or service that wants it.
Even more strongly than the Onion architecture, your UI has zero dependency on the domain model - because it is generic. (Unless you start to customise the UI, in which case you risk losing the benefits of the NO pattern).
The principles of Onion could be further applied within the domain model - ensuring that all domain services, for example, are defined and used by interfaces only. I have seen some people try to have all interactions between domain objects pass through interfaces only, but I have never seen this be made to work at any scale and see little value in it. You might like to read up on the 'Cluster' pattern, which is a pattern for breaking up a very large complex domain model into independent clusters with a strict hierarchy of dependency. This pattern is not dependent upon NO, though in practice there would be little point in adopting it if you didn't also have the benefit of NO.
And here I come to my main point, and what led to the definition of the NO pattern in the first place. It is all very well adopting strict principles for separation of concerns across the architecture. But unless you can get to the point where both the persistence layer and the presentation layer are 100% derived, automatically, from the domain object model, you end up losing much of the advantage of that separation of concerns, because any change to the domain model implies changes to the other layers, indirectly if not directly. Modern ORMs have done a great job of the domain model to persistence layer mapping; Naked Objects did it for the domain model to UI layer.
In short, if you adopt a framework firmly committed to the NO principles, you will get the claimed benefits of Onion. If your desire or need is to build your own architecture and you want to adopt the Onion principles then that's fine, but it is not then worth trying to figure out how to somehow retrofit any of the NO principles to that custom architecture: it will be very hard, and you probably won't see any of the benefits.
What are DDD recommendations for inter-domain referencing design?
Should I try to connect them as "Matryoshka" (put one into another) or it is better to create upper-level "inter-domain" business service?
P.S. Crossing this smooth water, I was unable to find anything useful to read in the Internet, and have started thinking that for this kind of things exist better term than "inter-domain referencing"... Am I right?
DETAILS:
I have two models/business services.
Semantically first domain (A) is CRM with sell/maintenance process for our goods, second domain (B) is "design" data of our goods. We have two view points on our goods: from seller perspective and from engineer perspective.
Actually each model is effective ORM (Object-Relational Mapping) tool to the same database.
There are some inter-domain activities e.g. validations (e.g. sometimes we can sell things to smb. only if some engineering rules are valid).
From developer's point of view I have two clear possibilities (reference B in A or create new cross reference domain/service C ). But from designer perspective I am lost in understanding what kind of Business Service I have when I compose business logic from two different domains.
As far as I know, DDD has no strict rules for 'inter-domain' referencing. At the end of the day your domain model will have to reference basic Java or .NET classes. Or it may reference specialized date/time or graph library (aka 'Generic Domain').
On the other hand DDD has a concept of Bounded Context. And it has quite a few patterns that can be applied when you work at the boundaries of the system. For example 'Anticorruption Layer' can be used to isolate you from legacy system. Other integration styles can be used depending on how much control you have over external code, team capabilities etc.
So there is probably no need to introduce artificial glue layer if you just dealing with two subdomains in one Bounded Context. Might also be worth reading Part 4 of DDD book (Strategic Design).
UPDATE:
Based on the information you provided, it looks like you only have one Bounded Context. You don't seem to have 'linguistic clashes' where the same word have two different meanings. Bounded Context integration patterns are most likely not applicable to your situation. Your Sales domain can reference Products domain directly. If you think of Products domain being more low-level and Sales being high level you can use Dependency Inversion Principle. Define an interface like ProductCompatiblityValidator in Sales and implement it in Products domain. And then inject the actual implementation at the application layer. This way you will not have a direct reference from Sales to Products.
In addition to what Dmitry has already said...
I think of any code that crosses bounded contexts as application layer code. I would have that application layer code reference domain types from both contexts (and their repositories) but not have two domains reference each other. I think it's OK to have business logic in an application layer if it specifically crosses domain boundaries and is unit-testable.
If you really have a hierarchy, then it would be OK to have the the more concrete subdomain reference the more abstract domain. However, I would be careful if this causes you to need to have domain objects reference repositories of any type. Pulling objects out of of a repository is rarely a true domain concept. Referencing repositories is best done in an application layer that sits a layer above the domain model.
Of course this is all as much art as science. I'd try modeling a thin slice of your application a couple different ways and see what friction you run into with each approach.
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.
I've always developed code in a SOA type of way. This year I've been trying to do more DDD but I keep getting the feeling that I'm not getting it. At work our systems are load balanced and designed not to have state. The architecture is:
Website
===Physical Layer==
Main Service
==Physical Layer==
Server 1/Service 2/Service 3/Service 4
Only Server 1,Service 2,Service 3 and Service 4 can talk to the database and the Main Service calls the correct service based on products ordered. Every physical layer is load balanced too.
Now when I develop a new service, I try to think DDD in that service even though it doesn't really feel like it fits.
I use good DDD principles like entities, value types, repositories, aggregates, factories and etc.
I've even tried using ORM's but they just don't seem like they fit in a stateless architecture. I know there are ways around it, for example use IStatelessSession instead of ISession with NHibernate. However, ORM just feel like they don't fit in a stateless architecture.
I've noticed I really only use some of the concepts and patterns DDD has taught me but the overall architecture is still SOA.
I am starting to think DDD doesn't fit in large systems but I do think some of the patterns and concepts do fit in large systems.
Like I said, maybe I'm just not grasping DDD or maybe I'm over analyzing my designs? Maybe by using the patterns and concepts DDD has taught me I am using DDD? Not sure if there is really a question to this post but more of thoughts I've had when trying to figure out where DDD fits in overall systems and how scalable it truly is. The truth is, I don't think I really even know what DDD is?
I think a common misconception is that SOA and DDD are two conflicting styles.
IMO, they are two concepts that work great together;
You create a domain model that encapsulates your domain concepts, and expose entry points into that model via services.
I also don't see what the problem is with ORM and services, you can easily use a session/uow per service call.
Just model your service operations as atomic domain commands.
a naive example:
[WebMethod]
void RenameCustomer(int customerId,string newName)
{
using(var uow = UoW.Begin())
{
var customerRepo = new CustomerRepo(uow);
var customer = customerRepo.FindById(customerId);
customer.Rename(newName);
uow.Commit();
}
}
Maybe the problem you are facing is that you create services like "UpdateOrder" which takes an order entity and tries to update this in a new session?
I try to avoid that kind of services and instead break those down to smaller atomic commands.
Each command can be exposed as an operation, or you could have a single service operation that receives groups of commands and then delegate those to command handlers.
IMO, this way you can expose your intentions better.
The most important things about Domain-Driven Design are the big picture ideas:
the ubiquitous language,
the strategic decision-making where you are adding value by working in the core domain (and insulating yourself from other nasty systems), and
the approach to making testable, flexible designs by uncoupling infrastructure from business logic.
Those are broadly applicable, and are the most valuable pieces.
There is a lot of design-pattern stuff about Factories, Services, Repositories, Aggregates, etc., I take that as advice from one experienced developer to another, not as gospel, because so much of it can vary depending on the language and frameworks that you're using. imho they tend to get overemphasized because programmers like us are detail-oriented and we obsess on that kind of stuff. There is valuable stuff there too, but it needs to be kept in perspective. So some of it may not be that relevant to you, or it might grow on you as you work with it.
So I would say it's not like there's a checklist that you can run through to make sure you're using all the patterns, it's a matter of keeping the big picture in mind and seeing how that changes your approach to developing software. And if you pick up some good tips from the patterns that's great too.
Specifically with respect to the SOA thing, I've developed applications that defer all their state to the database, which have used persistence-ignorant domain objects. Writing tests for services that have to mock daos and feed stuff back is drudgery, the more logic I can put in the domain objects the less I have to mess with mocks in my services, so I tend to like that approach better.
There are some concepts introduced with DDD which can actually confuse you when building SOA.
I have to completely agree with another answer, that SOA-services expose operations that act as atomic commands. I believe that a very clean SOA uses messages instead of entities. The service implementation will then utilize the domain model to actually execute the operation.
However there is a concept in DDD called a "domain service". This is slightly different than an application service. Typically a "domain service" is designed within the same ubiquitous language as the rest of the domain model, and represents business logic that does not cleanly fit into an entity or value.
A domain service should not be confused with an application service. In fact, an application service may very well be implemented such that it uses a domain service. After all, the application services can fully encapsulate the domain model within SOA.
I am really really late in this, but I would like to add the following in the very good answers by everyone else.
DDD is not in any conflict with SOA. Instead, DDD can help you maintain a better Service Oriented Architecture. SOA promotes the concept of services, so that you can define better boundaries (oh, context boundary is also a DDD concept!) between your systems and improve the comprehension of them.
DDD is not about applying a set of patterns (e.g. repository, entities etc.). DDD is mostly about trying to model your software, so that all the concepts (i.e. classes in case of object-oriented programming) align directly with concepts of the business.
You should also check this video (especially the last 5 minutes), where Eric Evans discusses exactly this topic.
I've even tried using ORM's but they just don't seem like they fit in
a stateless architecture.
I don't have any reference handy to back this up. However, you're right, ORMs do not fit nicely with DDD as well. This is because, they're trying to bridge the object-relational impedance mismatch, but in a wrong way. They force the software towards an anemic domain model, where classes end up being "plain data holders".
I am starting to think DDD doesn't fit in large systems but I do think
some of the patterns and concepts do fit in large systems.
In the video I've linked above, you can also find Eric explaining that DDD concepts can "break" in very large-scale systems. For instance, imagine a retail system, where each order is an aggregate containing potentially thousands of order items. If you'd like to calculate the order's total amount strictly following DDD, you'd have to load all the order items in memory, which would be extremely inefficient compared leveraging your storage system (e.g. with a clever SQL statement). So, this trade-off should always be kept in mind, DDD is not a silver bullet.
Like I said, maybe I'm just not grasping DDD or maybe I'm over
analyzing my designs?
Excuse me, but I'll have to quote Eric Evans one more time. As he has said, DDD is not for perfectionists, meaning that there might be cases, where the ideal design does not exist and you might have to go with a solution, which is worse in terms of modelling. To read more around that, you can check this article.