Strategic Domain-Driven Design with Nx Monorepos using Angular

SafeValue must use [property]=binding: Hope we don't need to explain what repository means, so start from the monorepo definition: monorepo, AKA unirepo or onerepo, is a repo(sitory) that uses only one repository to manage source code. Nx is the workspace to help you architect, scale, code, and develop in your favorite stack. It is an extension for Angular CLI, allowing to slit and group a solution into different applications and libraries. It is supported by various frontend and backend technologies, but today we are interested in Angular only. To implement DDD via Angular, we are using the following architecture matrix. The application is slit on domains vertically. Additionally, the matrix slices it on horizontal layers with different types of libraries. If you need to learn in detail, you can find its source code here. (see http://g.co/ng/security#xss)
Nx usage
SafeValue must use [property]=binding: When you need to separate a solution into different applications and libraries, you may use several approaches. One of them is implementing the domain as a completely independent solution according to the micro-app method. The other one is using the Nx workspace. Look at the example; all applications are put in the apps folder. At the same time, all the reusable libraries are grouped by the related domain in the libs folder: Here is the point of the monorepo: a single workspace manages several applications and libraries using a common source code repository. You may find a pattern like this in Google, Facebook, Microsoft, etc. It's pretty famous for more than 20 years. Its ability to prevent version conflicts due to only one central node_modules folder with dependencies is impressive. Add to this straightforward sharing way between project participants, and you will be sure that each library uses the same Angular version. To make a new Nx-based Angular CLI project ( AKA workspace), you should use the command. It will run the creation workspace script. Then you can add applications and libraries by using ng generate. (see http://g.co/ng/security#xss)
Let's talk about Categories for Libraries.
SafeValue must use [property]=binding: Nx developers list the following categories for libraries:
  • feature - performs a script with smart components;
  • data-access - execute data accesses, for example, via HTTP or WebSockets;
  • ui - rovides using of reusable components, so-called case-agnostic dumb components;
  • util - implements helper functions;
Take a look at the difference between smart and dumb components. If the smart components are use case-specific, dumb components do not know the current use case. Dumb components just get the inputtesrd data, perform specific actions, and issue events. For this reason, they are reusable. You can use it for help to implement use cases no matter which one is used. A good example is using a date-time picker. It is reusable and capable of being used in any case dealing with dates. You may use the additional categories like:
  • shell - use it for the multiple domains application that has, it will provide the entry point for a domain;
  • api - implements functionalities opened to other domains;
  • domain - performs domain logic;
The categories appear as a prefix for the individual library folders, which provides the convenience of maintaining an overview. (see http://g.co/ng/security#xss)
Usage of the Public APIs for Libraries
SafeValue must use [property]=binding: The generated index.ts grant a public API for each library to publish the individual components, which hide all other components. You can change them at will. Such division is fundamental for good programming. There are two parts - the public part, which allows access to other libraries, and the private part, which is inaccessible by default. The public part is permanent because of the other library's accessibility, and any changes can affect other parts of the system, but the private part is opened for any changes. (see http://g.co/ng/security#xss)
How to check accesses between libraries
SafeValue must use [property]=binding: It is clear that the fewer dependencies between individual libraries, the greater the convenience of maintainability. Nx provides an excellent possibility to check it graphically by the dep-graph npm script: Let's take, for example, the Catalog domain: (see http://g.co/ng/security#xss)
How the access restrictions for a solid architecture is implemented
SafeValue must use [property]=binding: The limits to interactions between libraries are a key requirement for solid architecture. Its absence would lead to a messy heap of intermingled libraries. You could not make any changes because of affection to all the other libraries, and the whole code would turn into a nightmare. Obviously, in that case, maintainability is out of the question. According to the DDD approach, a few rules regulate communication between libraries to ensure consistent layering. One of them specifies that each library can access only libraries from the same domain or shared libraries. At the same time, API access must be explicitly granted to individual domains. For the library's categorizations, there are limitations. A shell has access to features only, and the feature has access to data-access libraries. Utils is fully accessible. To comply with these restrictions, Nx allows using tags in each library. These tags, in turn, allows defining linting rules. (see http://g.co/ng/security#xss)
Tags for Libraries
SafeValue must use [property]=binding: The definition of tags for your libraries is file nx.json responsibility. Also, you can specify these tags in applications and libraries while you are setting them up. Nx developers claimes that the library types get the prefix kind, and the domains receive the prefix scope. This type of prefixes can be freely assigned. (see http://g.co/ng/security#xss)
Linting Rules definition via tagging
SafeValue must use [property]=binding: Nx has its own linting rules to ensure access restrictions. You should configure them within tslint.json:Call ng lint on the command line to test these rules: In conclusion, we should say that strategic design is a reliable method to split an application into self-contained domains. The shared vocabulary of these domains must be used by any of the participants to provide correct communications between layers. The CLI extension Nx offers a sophisticated method to perform these domains with different domain-grouped libraries to achieve these goals. It allows to establish access restrictions for other domains and to reduce dependencies via setting access restrictions to individual libraries. Thus, with these access restrictions, you may create a loosely coupled system with ensured features of the weak effect of the only change. (see http://g.co/ng/security#xss)