Object Oriented Analysis and Design and DDD together

domain-driven-designobject-oriented-designooad

I fear this question seems to broad, so I'll try to explain what I mean with some detail. I couldn't, however, find a way to divide it into other questions. If that's really the case, I gladly accept suggestions on how to break this question down in more focused ones.

I work with object oriented programming and one of the first things I've heard about was the process of OOAD where starting with requirements, mainly in the form of use cases, we figure out the domain model classes we are going to need and the relationships between those classes.

On the other hand, on the last few weeks, I've been studying about Domain-Driven Design and there are many things that seems to help a lot with object oriented design. One of those is the division of the application with bounded contexts which solves the problem of confusions about the meaning of a certain term from the domain. Another things that seems to help a lot is the idea of entities, value objects, aggregates, repositories, factories, services and domain events.

Now, when programming, it's clear how we implement lots of those things with object orientation and classes. My doubt is: how we can join the process of OOAD and the use of DDD?

I mean, when planing, without coding anything, how do we join OOAD and DDD? OOAD puts enphasis on some work on paper before coding, like use cases, user stories, diagrams and so on. DDD doesn't seem to talk about this kind of things. How DDD enters this design phase of the project?

I imagine something like this: we first understand the domain, then divide it into subdomains, then for each subdomain we perform the process of OOAD, writing use cases and so on and when making the classes we keep in mind DDD ideas. Is it like that?

Best Answer

Eric Evans has said that DDD is just (one flavor of) good object-oriented design. He just wrote it down and gave it a catchy name. The two are not at odds, they are, in fact, one and the same.

Related Solutions

Domain-Driven Design – What is a Bounded Context?

Bounded Contexts and Subdomains exist at different levels.

A Subdomain is a portion of the problem space, it's a natural partitioning of the system, often reflecting the structure of the organisation. So logistics and operations might be separated from invoicing & billing. Eric differentiates core, supporting and generic subdomains according to their business relevance in the given scenario.

Contexts are portions of the solutions space. They're models. It would be a good thing to have them, reflect the domains-subdomains partitioning ...but life isn't always that easy. And you might have bloated legacy domain encompassing everything, or more context in the same subdomain (i.e. old legacy app the replacement app somebody is building).

To have a Bounded Context you need to have a model, and an explicit boundary around it. Exactly what's missing in many data-driven application that use databases to share data.

Another - orthogonal - way to see it may be the following. Ubiquitous Language, the special condition where every term has a single unambiguous definition, doesn't scale. The more you enlarge it, the more ambiguity creeps in. If you want to achieve precise, unambiguous models, you need to make their boundaries explicit, and speak many little Ubiquitous Languages, each one within a single Bounded Context, with a well defined purpose.

Architecture – What are subdomains, really

Disclaimer: I'm not a DDD expert, but I'm going to do my best here to answer your questions.

Let's use an Online Book Retailer as an example. A book seller is offering to sell books on his website, but he doesn't print the books himself. Instead, he has a long list of "Book Suppliers" who print and ship the books to his warehouse, were he packages them and ships them to the customers all around the world.

Could you imagine the teams working in that company?

The listing team: The team that selects which books they should list on the Website, depending on the stock of the suppliers.
The fulfillment team: responsible for collecting the orders from the Website and managing the orders' life cycle.
The commercial team: these are the guys who handle adding or removing suppliers from the system.
The marketing team: responsible for the campaigns and offers.
The warehouse team: responsible for collecting books from the suppliers and shipping them.

Each team will use its own terms to describe what it is doing. Teams will use the domain language or the "Ubiquitous Language", as Eric Evans calls it. Normally, each team will have a different mental model of what an entity is. For example:

Listing team: BOOK(book_id, ISBN, title, price, weight, length, width )  
Fulfillment team: BOOK(book_id, totalPrice, sold_quantity)   
Shipping team: ITEM(book_id, delivery_date) --> they refer to the book entity as "item"

A sub-domain is one particular part of the domain, in which some users use a certain Ubiquitous Language. When the language changes, this is an indication the you are crossing into another sub-domain.

What if two teams use the same terms? Both the fulfillment and listing teams call book "book". You will have to ask them, "what is a book for you? What are its key attributes? How is it used?"

Answers to these question will result in two different or similar domain models. The greater the difference between the two models, the more indication that these are two different Bounded Contexts/sub-domains. The opposite is also true. The more similar the two models are, the more likely that they should be part of the same sub-domain.

This may result in very interesting findings in your model. You may discover that inside the fulfillment sub-domain, the orders pass through different states (new -> requested -> shipped). Maybe each of these states requires complex management and different attributes, so you may divide this sub-domain into several other sub-domains.

This brings out a question of what the size of the sub-domain(s) should be. The answer is "let the domain model decide that". Whenever you see a change in the UL and model, then draw a boundary for that sub-domain.

Remember that DDD is all about the business, the people and the communication(s) between them. Let that drive your model.

Best Answer

Related Solutions

Domain-Driven Design – What is a Bounded Context?

Architecture – What are subdomains, really

Related Topic