I struggled with this too, the first time I was exposed to this approach. The practical role of the domain object is to be the model which controls all possible mutations to its instances. That domain class is the only place where domain objects are allowed to mutate (and those mutations can only be called from use cases). See an example in the Ingredients domain the repo.
Only use cases are allowed to access domain objects. Having a single place where domain objects can mutate, and a single way to do it, is one way to manage increasing complexity and maintain control over your code.
So ideally you don't store domain objects in the store, because having them in the store will give devs the (wrong) impression that they are allowed to access domain objects in components (specially with how easy it is to pull store data into components from Vuex or Pinia stores). The domain is better protected from unexpected changes if they are not saved in the Store.
Remember your Store should ideally just be another tool for your Secondary layer (same as API and LocalStorage). So what you hold in your Store should be something that your secondary can transform into domain objects before passing them on to the use case that requested it.
It is very clear and I now understand why it is designed that way. Thank you again for sharing such an excellent article, I am very interested in front-end DDD and I am planning to practice it in my project.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hello, why do you need a domain object type? What is its role? Can you directly store the domain object as a type in the store?
I struggled with this too, the first time I was exposed to this approach. The practical role of the domain object is to be the model which controls all possible mutations to its instances. That domain class is the only place where domain objects are allowed to mutate (and those mutations can only be called from use cases). See an example in the Ingredients domain the repo.
Only use cases are allowed to access domain objects. Having a single place where domain objects can mutate, and a single way to do it, is one way to manage increasing complexity and maintain control over your code.
So ideally you don't store domain objects in the store, because having them in the store will give devs the (wrong) impression that they are allowed to access domain objects in components (specially with how easy it is to pull store data into components from Vuex or Pinia stores). The domain is better protected from unexpected changes if they are not saved in the Store.
Remember your Store should ideally just be another tool for your Secondary layer (same as API and LocalStorage). So what you hold in your Store should be something that your secondary can transform into domain objects before passing them on to the use case that requested it.
It is very clear and I now understand why it is designed that way. Thank you again for sharing such an excellent article, I am very interested in front-end DDD and I am planning to practice it in my project.