3

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.

Golo Roden
  • 140,679
  • 96
  • 298
  • 425
choquero70
  • 4,470
  • 2
  • 28
  • 48

4 Answers4

6

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.

guillaume31
  • 13,738
  • 1
  • 32
  • 51
  • Ah! @guillaume31 That make sense, and it answers another doubt I had, about wether the application layer speaks the UL too. If it didn't then it couldn't offer service methods with a meaningful name. This make me think about another thing I don't understand then: why the application layer must hide the domain objects to the client by translating them to DTOs. The application layer offer services named with the UL but the args are primitives types instead of domain objects. – choquero70 Mar 01 '18 at 21:19
  • 1/ because you don't want the client/UI to act directly on domain objects (remember that they have rich behavior). 2/ because use case operations might not be exact 1-to-1 matches with domain operations. You need a reverse funnel shaped workflow with one applicative action causing multiple domain ones. – guillaume31 Mar 02 '18 at 08:19
0

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.

Golo Roden
  • 140,679
  • 96
  • 298
  • 425
  • Thank you. I will take a look at your links. I know what you mean in your answer, that's my undestanding too. But then I wonder if DDD is practical from the user point of view. If you don't have in mind the user stories while developing the domain model, then maybe for example, that you are developing a model too large for what you really need. My doubt also came when I read about using BDD with DDD. BDD is user story oriented first, and then you would develop the domain model according to the behaviour you need – choquero70 Mar 01 '18 at 00:25
0

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.

mgonzalezbaile
  • 1,056
  • 8
  • 10
  • what you say is what happened to me in the project I was developing. My domain model had concepts that then I realized I didn't need. That's why I asked if design of the domain model can be driven from the use cases, so that you just model the part of the domain you need. From your answer and others, I see that it can be done. Thank you – choquero70 Mar 02 '18 at 21:15
0

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.

rascio
  • 8,968
  • 19
  • 68
  • 108
  • Well @rascio I'm not sure but I think that what you explain is more or less the whirlpool process by Eric Evans? After reading all the answers I think that in the end DDD is driven by the use cases or user stories or whatever we call them , because we begin to discover and create the model and the UL from those desired user functionality . – choquero70 Mar 03 '18 at 23:18
  • I don't know about the "whirlpool process". But in the end I think that DDD is driven by use case, the domain model is a side effect of the use case you need to implement, more complex use cases means a more complex domain. My answer was "driven" by the phrase "it is supposed that you develop the domain model first", but this to me seems a big analysis *before* you start developing, but it is developing that you get insights about the use cases, and the domain model. – rascio Mar 05 '18 at 13:37
  • Hi @rascio , I said «it is supposed you develop the domain model first» supposing that the word «domain» in «domain-driven design» means the domain layer, so that you have to implement the domain layer (model) first and then it «drives» the rest of the application. This wouldnt take into account the use cases or the needs of the user neither. And it would mean that you have to implement the whole domain first. As you said, this isnt the way. You always have to have the user in mind and model the domain accordng to what he needs. – choquero70 Mar 05 '18 at 16:33
  • Yes, you should check the EventStorming tecnhique if you don't know it. It is a lot related with your question, you can start from here http://ziobrando.blogspot.it/2013/11/introducing-event-storming.html and then google will help – rascio Mar 06 '18 at 15:35
  • I know what event storming is, thank you. I like a lot «user story mapping» too, by Jeff Patton. – choquero70 Mar 06 '18 at 20:07