What domain driven design mean for Javascript applications on the client side?

Question

What domain driven design mean for Javascript applications on the client side?

I want to build an application based on ddd approach with javascript.

The framework I'll use to implement the application is not important to me because I want to learn how to organize the code according to ddd architecture.

Let's decide module is folder.

My application is have login, notifications, reports, crud operations, and shared stuff, and each of them have api-server logic, ui components, services and crud.

For example auth folder contains the following

 api               --> server logic
 domain            --> the domain itself. the bl: handle the data, use of http.
 feature-login     --> the page itself containers of ui elements. 
 feature-register  --> the page itself containers of ui elements.
 ui                --> ui elements for auth domain
 utils             --> utils functions for auth domain

same goes for notification folder:

 api               --> server logic
 domain            --> the domain itself. the bl: handle the data, use of http.
 feature-create    --> the page itself containers of ui elements. 
 feature-list      --> the page itself containers of ui elements.
 ui                --> ui elements for notification domain
 utils             --> utils functions for notification domain

And reports:

 api               --> server logic
 domain            --> the domain itself. the bl: handle the data, use of http.
 feature-dashboard    --> the page itself containers of ui elements. 
 feature-search      --> the page itself containers of ui elements.
 feature-edit      --> the page itself containers of ui elements.
 feature-view      --> the page itself containers of ui elements.
 ui                --> ui elements for report domain
 utils             --> utils functions for report domain

This is how I build my application.

So Where is my problem here?

According to ddd the domain is shouldn't be share inside other domains. because it's create decoupling.

But in the report domain I need to get the user from auth domain and need to display notification from notification domain.

This is makes decoupling between the domains.

So it's lead me to realize maybe I don't defined my domain correctly? my folder structure is matching the ddd principle? if no how I do I decide what is domain and what is not?

Answer 1

DDD does not say that you can not access an entity from another entity.

You should group your entities by aggregate and identify the root aggregate.

The root aggregate will be then use in order to access the entities.

The presentation layer will acces the domain via an application service.

Answer 2

The problem is that here you are doing a technical cut and not a business cut.

In DDD, before moving on to the code phase using tactical patterns, there is a strategic phase.

In this strategic phase, thanks to a business expert, you will be able to use the different strategic patterns: Ubiquitous language, division and identification of sub-domains, strategy around Bounded Context.

Without this phase, you do what we call "DDD lite" and one of the problems linked to this is the one you raise.

Ok to have separated your auth domain (authentication is almost always a generic sub-domain) but why did you separate your notification and report sub-domains? Are you sure this is the right decision?

If you want to practice without a business expert, maybe you should do a mini Event Storming first?