Nx calls a group of feature, ui, util and data-access libraries a domain. I also include the shell type.
Even though nx recommends using domains, by default all operations must happen at the level of libraries. For example, you cannot rename a domain. You need to instead rename all the libraries inside a domain. This is cumbersome. The domain schematics allow you to perform operations at the domain level.
Beyond what was discussed in the post, I see domains being used in the following ways:
They include the cypress and storybook code. Instead of this code existing in a separate apps folder it exists under folders in the domain.
There can be parent and child domains. For example, you might have a cash account page which would have a number of domains in it like transaction history, account details etc. cash-account would be the parent domain (just a grouping folder) and it would include multiple child domains inside of it.
Shared can be at the child domain level, i.e. you can have shared at the level of:
the application grouping folders which means it can be used in any domain across any application
inside an application grouping folder which means it can be used by any domain in a specific application
inside a parent domain grouping folder which means it can be used by any child domain in a parent domain
In DDD, the domain relates to the whole business. It groups the business logic, the language, and the practices of the domain experts, stakeholders, and participants of a given industry, business, etc.
Similar domain problems can be solved by different entities in different ways creating different domains. The domain is then specified by the problem, the solution, and the language around it.
Each domain can as you described contain different subdomains. Bounded Contexts are the Software representation/implementation of those subdomains but they don't necessarily match 1-1.
This is a brief description of some more complex terms, but for the sake of the conversation, it is good to be on the same page.
The wide picture is that the domain is only one and can be split into multiple subdomains that are reflected in the code as Bounded Contexts.
I'd take a look at your code sounds interesting!
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.
For Angular projects, I created this project for domain schematics and a related vscode extension that makes it easier to use.
Nx calls a group of feature, ui, util and data-access libraries a domain. I also include the shell type.
Even though nx recommends using domains, by default all operations must happen at the level of libraries. For example, you cannot rename a domain. You need to instead rename all the libraries inside a domain. This is cumbersome. The domain schematics allow you to perform operations at the domain level.
Beyond what was discussed in the post, I see domains being used in the following ways:
In DDD, the domain relates to the whole business. It groups the business logic, the language, and the practices of the domain experts, stakeholders, and participants of a given industry, business, etc.
Similar domain problems can be solved by different entities in different ways creating different domains. The domain is then specified by the problem, the solution, and the language around it.
Each domain can as you described contain different subdomains. Bounded Contexts are the Software representation/implementation of those subdomains but they don't necessarily match 1-1.
This is a brief description of some more complex terms, but for the sake of the conversation, it is good to be on the same page.
The wide picture is that the domain is only one and can be split into multiple subdomains that are reflected in the code as Bounded Contexts.
I'd take a look at your code sounds interesting!