Can feature be share by default? or have the option to make it share?

[wizardnet972]

Hi @manfredsteyer ,

(edit due to confusion)

Can feature be share by default?

Please consider this case:

In my application I have notification domain. this notification folder under libs folder have domain contains all the services for create, delete and update notification.

Also this folder contains features such create new notification and shell page to display all notifications in the list.

Now my client want to have a button in the app-shell component. when I click this button then should popup a create notification component from notification folder under libs folder.

So notification which is feature-domain must be use in app-shell from core domain.

One way I think about is to export the feature using public-api lib. (In order not to break the roles). Another way is to export the dumb component and the domain service and reassemble them in the app-shell component and everywhere I need to use them.

Both not breaking the ddd roles.

But they not easy to implement. Maybe if it's possible to have share tag to the features?

From your experience. What do you think?

[gernsdorfer]

In my opinion, I would split the API Module into domain-api and shell-api. ddd.pdf

• The corresponding eslint boundaries config could look like this:

  • Feature

    {
    "sourceTag": "type:feature",
    "onlyDependOnLibsWithTags": ["type:ui", "type:api", "type:domain", "type:util"]
    },

  • Boarding

    {
    "sourceTag": "domain:boarding",
    "onlyDependOnLibsWithTags": ["domain:boarding", "domain:booking/domain-api", "domain:booking/shell-api", "domain:shared"]
    },

• The corresponding nx boundaries config could look like this:

  "booking-domain-api": {
   "tags": ["domain:booking", "domain:booking/domain-api", "type:API"]
  },
  "booking-shell-api": {
   "tags": ["domain:booking", "domain:booking/shell-api", "type:API"]
  },

The benefit of splitting the API into shell-api and domain-api is, that a shell-api should be lazy loaded and has no effects to the current Feature Module bundle size. A domain-api could not be lazy loaded and increase the bundle size.

[manfredsteyer]

We don't do this by default, because it could cause cycles. however, feel free to adjust the generated rules.