I fear this question seems too 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 will 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 thing 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 planning, without coding anything, how do we join OOAD and DDD? OOAD puts emphasis 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?
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.
3
I have been reflecting on Applying UML and Patterns by Craig Larman and Domain-Driven Design by Eric Evans and although both seem to tackle the same problem from a bird’s eye view, they have different philosophies.
OOA/D is sort of ‘waterfall-y’ because you derive a model from the requirements using ‘real-world objects’ and translate it into a class diagram which you implement afterwards.
Evans on the other hand says that you should develop a Domain Model which helps you build a common language – the Ubiquitous Language – which everybody on the team speaks and understands. There is no analysis and design in the OOA/D-sense.
Starting from the Domain Model and the Ubiquitous Language the domain experts can write more precise use-cases and the developers can try to implement the domain model. If the implementation doesn’t resemble the domain model it doesn’t mean it’s wrong but it means it doesn’t work in your case so you have to refine it. If the domain experts can’t phrase sensible use-cases again it doesn’t mean it’s wrong. It’s just that something’s missing and the domain model should be reviewed.
According to Evans this feedback loop is crucial when doing DDD.
This is probably more of a text book approach. Out ‘in the wild’ the two might not be so different.
As to how to integrate the two: Building a Domain Model and the Ubiquitous Language should be part of an early workshop. If there already are some use-cases you can validate those by talking about them. If there aren’t, well, it’s going to be much easier to write them now.