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?