Can domain-driven design be use-case driven?

Question

Maybe the question is a contradiction, but is it correct in DDD to start the development from the use cases, and then you develop the domain model that will support those services?

If the design is driven by the domain (as DDD says), it is supposed that you develop the domain model first (by understanding the problem domain and using the Ubiquitous Language), and then you develop the application layer (use cases) that will use the domain.

However it seems that in DDD you start from the use cases (or user stories) first and then you develop the domain model.

Answer 1

DDD doesn't imply any "order" in the implementation.
But, it put a lot of effort in understanding the domain and make it the most explicit as you can.
Depending on the project it can take months to have a good understanding of the domain, and I think the software should evolve togheter with the team knowledge of the domain.

So, I think you should start (in a very agile mood) from use cases, write tests, implement/evolve the domain, complete the use case, make the tests pass, be sure everything is ok and go with the next use case.

So that the domain layer in your application is continuously evolving and will be refined with new concepts and understanding of your domain as you gain more knowledge about it.

UPDATE
The hard part of this approach, is maintain fast development of use cases, so having easy refactor of your model. To do this all the clean code, design patterns, and all the tricks discovered to do a "good" code helps.
What can be very hard to refactor can be the persisted data. Having a data structure refactor of persisted data can be very painful, for this the event sourcing technique is a lot associated with DDD.
(In a simplicistic way) It is centered on storing immutable data structure, and your "domain model" is just an in memory projection of these data, so that you can refactor your model without having to refactor the persisted data.

Answer 2

Based on my experience I would suggest starting the implementation from the use case (application layer). Here some reasons:

• User Stories come in the form of use cases: "register an user", "place an order", etc, etc. So to me it's more natural to start coding from there.
• Since the output of the use case is a state transition by returning/publishing some events from the domain, I use them to create first the tests as follows:

.

given(new User("an id", "inactive_email@example.com"))
.when(new ActivateUserEmailCommand(input))
.then(new EmailUserWasActivated())

• Once I've implemented a test for each of the different scenarios my use case can go through I could even pass the test class to another person (maybe someone with less experience) and let him implement it since most of the UL is already defined in the test itself.

• One benefit I see is that you just implement the minimum amount of code to make your use case work. This way you avoid figuring out which attributes your Aggregate Root will need in advance, but just focus on the ones you need for the specific use case.

• By implementing just the use case (along with the tests and domain), your PR will be way easier to be reviewed since reviewers see just what is used, and they shouldn't find attributes/parameters that are not used yet because it'll be harder for them to understand what's the reason behind adding them.

Answer 3

If the design is driven by the domain (as DDD says), it is supposed that you develop the domain model first (by understanding the problem domain and using the Ubiquitous Language), and then you develop the application layer (use cases) that will use the domain.

However it seems that in DDD you start from the use cases (or user stories) first and then you develop the domain model.

Neither of these statements is accurate. The -driven part of DDD doesn't imply a particular order in the implementation of the system. It just says that that the whole design and coding effort should be primarily centered around the domain and its language.

You can equally choose to implement the application layer first as the domain layer first. Regardless, a logical model of the domain will need to be there before you start implementing. Use cases speak the same language as the domain model - it would make no sense to develop the application layer without at least a well-defined ubiquitous language and sketched model of the domain.

Answer 4

As the name domain-driven design suggests, the domain is at the center. So you model the domain first.

Therefore you need to talk to the domain experts, and you need to build a good understanding of the domain for everyone in your interdisciplinary team. Part of this is to find / create the ubiquitous language that ensures that everybody means the same things with the same words, so your goal is to eliminate redundancy and misunderstandings, that are based on unclear terminology.

I have written a blog post series on DDD and co., which may be of interest to you. Also, I have written this blog post at the Auth0 blog, which describes how to model and build a software from scratch using DDD, event-sourcing and CQRS, and wolkenkit, an open-source CQRS and event-sourcing framework for JavaScript and Node.js.

Once you have the domain model and your ubiquitous language, you can start to define user stories. Actually, this is a pretty simple task once you have modeled your domain.