search

nrwl / board-game-hoard

20 stars 23 forks source link

nx-enforce-module-boundaries for data access library #2

Open sameerinfodb opened 4 years ago

sameerinfodb commented 4 years ago

In board-game-hoard sample data-access library can only depend on util library , as per mono repository pattern book from Nrwl team , A data-access library cannot depend on a feature or ui library which implies that data-access library can depend on data access and util.

where board game hoard sample has following boundaries.

"sourceTag": "type:data-access", "onlyDependOnLibsWithTags": ["type:util"]

Please confirm.

isaacplmann commented 4 years ago

Yes, that makes sense.

type:data-access should be able to depend on type:util or type:data-access

sameerinfodb commented 4 years ago

mono repository pattern book states this "sourceTag": "type:feature", "onlyDependOnLibsWithTags": [ "type:ui", "type:data-access", "type:util" ] and at the same time if we set following boundary with expectation of re-using shared feature library "sourceTag": "scope:booking", "onlyDependOnLibsWithTags": [ "scope:booking", "scope:shared", "scope:common" ]

then second boundary will not hold good where in we have shared library of type feature and app specific library with type feature then app-specific library cannot depend on shared library with type feature. How to overcome this problem. if you can suggest it will be great help. thanks

isaacplmann commented 4 years ago

You have two options:

  1. Don't try to share feature libraries. Each app would then use a shared data-access and ui library in its own feature library.
  2. Relax the type:feature restrictions to allow a feature to depend on another feature.

The patterns described in the monorepo book are a starting point (not a firm law), from which each organization can evolve and write their own rules that fit their context.

sameerinfodb commented 4 years ago

Thank you for your suggestion @isaacplmann.

sameerinfodb commented 4 years ago
  1. Relax the type:feature restrictions to allow a feature to depend on another feature.

I was thinking about your suggestion then, i got this thought in mind why don't we have a new library type called feature-shell wherein we can allow it to dependent on more than one feature that way we can honor the rule of feature dependency over data-access, ui and util in feature library and use more than one feature via feature-shell type libraries.

What is your thought about it?

Thanks,