This lesson may be a surprise for you.
I won't convince you to switch from one architecture to another because it's better or something.
We're not going to describe the advantages or disadvantages of architectures you can build with NX mono repositories.

Every project is different, and the architecture that works on my projects may not suit you.
Knowledge about the context, customer, and team needs is the key to a successful code organization.

In this lesson, we'll focus on NX features that will help you organize your applications and libraries.

No matter which architecture you're using, almost all of them have some rules that you need to enforce.
For example, in Domain Driven Design
(

)
you want to isolate the domain, so your components will use only methods exposed by API services.
The other example you may approach is hexagonal architecture.
Components in this approach can communicate using ports.

These rules are very often related to the code decomposition.
In huge simplification, you want to ensure that some code will not be used in some classes.

In the case of NX, we can make sure that programmers will not be able to import libraries that shouldn't be used in other libraries.


Like in hexagonal architecture, you can use only ports outside the domain.

NX provides a nice solution that you can use to control the usage of libraries in other libraries.
It's universal and should be easy to adapt to any kind of architecture.

The feature I'm describing is called tags.
You can tag your libraries, tools, or applications.
There are no predefined tags you should use.
A tag is a simple string that has a meaning for you and your team.
What's more, you can set any number of tags you want, which allows you to focus on multiple aspects of your library.

You may think now: "Okay, but how will tags help me?
How can NX validate my imports using these tags that I set?"

Of course, when you set your tags, NX has no idea what you want to do.
You need to configure that part.
NX comes with an eslint rule that will allow you to complete the goal.

Let's jump to the code and check how it works.

For example, I'm generating an application and three libraries to mirror the example in the image above.

In this lesson, we don't need to focus on the library code, so I will leave the default code generated by NX.

npx create-nx-workspace --pm yarn
yarn add -D @nx/angular
yarn nx g @nx/angular:app apps/app --prefix app
yarn nx g @nx/angular:lib libs/users-ui --prefix lib
yarn nx g @nx/angular:lib libs/users-api --prefix lib
yarn nx g @nx/angular:lib libs/users-http --prefix lib

In my design, I'm going to create a few tags:

Let's add these tags. All you need to do is to edit 

 inside of your application or libraries.

  "prefix": "app",
  "sourceRoot": "apps/app/src",
  "tags": ["type:app"],
  "targets": {
    "build": {
      "executor": "@angular-devkit/build-angular:browser",

  "prefix": "lib",
  "tags": ["type:lib", "lib:ui"],
  "projectType": "library",
  "targets": {
    "test": {
      "executor": "@nx/jest:jest",

---
title: Tips. Target architecture
description: Why defining a target architecture may be an important step of the migration process
code: https://gitlab.com/fullstackio/books/newline-course-apps/building-angular-applications-with-nx-app/-/tree/main/manuscript/code/06.06-tags?ref_type=heads
privateVideoUrl: https://stream.mux.com/WgyXRj1wFlRsyEVIBEZarQdxvqlg78rvbamwdaeMNO00.m3u8
---

This lesson may be a surprise for you.
I won't convince you to switch from one architecture to another because it's better or something.
We're not going to describe the advantages or disadvantages of architectures you can build with NX mono repositories.

Every project is different, and the architecture that works on my projects may not suit you.
Knowledge about the context, customer, and team needs is the key to a successful code organization.

**In this lesson, we'll focus on NX features that will help you organize your applications and libraries.**

## The problem

No matter which architecture you're using, almost all of them have some rules that you need to enforce.
For example, in Domain Driven Design
([angulararchitects.io blog post](https://www.angulararchitects.io/en/blog/tactical-domain-driven-design-with-monorepos/))
you want to isolate the domain, so your components will use only methods exposed by API services.
The other example you may approach is hexagonal architecture.
Components in this approach can communicate using ports.

![Simple architecture example](https://d2uusema5elisf.cloudfront.net/courses/building-angular-applications-with-nx/module_07/lesson_07.06/public/images/06-06-01.png)

These rules are very often related to the code decomposition.
In huge simplification, you want to ensure that some code will not be used in some classes.
**In the case of NX, we can make sure that programmers will not be able to import libraries that shouldn't be used in other libraries.**
Like in hexagonal architecture, you can use only ports outside the domain.

## Tags

NX provides a nice solution that you can use to control the usage of libraries in other libraries.
It's universal and should be easy to adapt to any kind of architecture.

The feature I'm describing is called tags.
You can tag your libraries, tools, or applications.
There are no predefined tags you should use.
A tag is a simple string that has a meaning for you and your team.
What's more, you can set any number of tags you want, which allows you to focus on multiple aspects of your library.

You may think now: "Okay, but how will tags help me?
How can NX validate my imports using these tags that I set?"

Of course, when you set your tags, NX has no idea what you want to do.
You need to configure that part.
NX comes with an eslint rule that will allow you to complete the goal.

Let's jump to the code and check how it works.

### Example

For example, I'm generating an application and three libraries to mirror the example in the image above.

In this lesson, we don't need to focus on the library code, so I will leave the default code generated by NX.

```bash
npx create-nx-workspace --pm yarn
yarn add -D @nx/angular
yarn nx g @nx/angular:app apps/app --prefix app
yarn nx g @nx/angular:lib libs/users-ui --prefix lib
yarn nx g @nx/angular:lib libs/users-api --prefix lib
yarn nx g @nx/angular:lib libs/users-http --prefix lib
```

In my design, I'm going to create a few tags:

-   `type:app` - for applications. The application can depend on libraries.
-   `type:lib` - for libraries. The library cannot depend on applications and can be used in other libraries.
-   `lib:ui` - for libraries that will contain UI components. It can be used in applications or other UI component libraries
-   `lib:api` - for libraries that contain services useful in applications. It can be used in applications, UI component libraries, or other API libraries
-   `lib:http` - for libraries that contain HTTP code. It can be used in UI component libraries or API libraries

Let's add these tags. All you need to do is to edit `project.json` inside of your application or libraries.

For `apps/app`:

```json { actualFilename=../../../manuscript/code/06.06-tags/apps/app/project.json endLine=10 startLine=5 statedFilename=apps/app/project.json url=https&#x3A;//gitlab.com/fullstackio/books/building-angular-applications-with-nx/module_07/lesson_07.06/.../../manuscript/code/06.06-tags/apps/app/project.json#L5 }
  "prefix": "app",
  "sourceRoot": "apps/app/src",
  "tags": ["type:app"],
  "targets": {
    "build": {
      "executor": "@angular-devkit/build-angular:browser",
```

For `libs/users-ui`:

```json { actualFilename=../../../manuscript/code/06.06-tags/libs/users-ui/project.json endLine=10 startLine=5 statedFilename=libs/users-ui/project.json url=https&#x3A;//gitlab.com/fullstackio/books/building-angular-applications-with-nx/module_07/lesson_07.06/.../../manuscript/code/06.06-tags/libs/users-ui/project.json#L5 }
  "prefix": "lib",
  "tags": ["type:lib", "lib:ui"],
  "projectType": "library",
  "targets": {
    "test": {
      "executor": "@nx/jest:jest",
```

For `libs/users-api`:

```json { actualFilename=../../../manuscript/code/06.06-tags/libs/users-api/project.json endLine=10 startLine=5 statedFilename=libs/users-api/project.json url=https&#x3A;//gitlab.com/fullstackio/books/building-angular-applications-with-nx/module_07/lesson_07.06/.../../manuscript/code/06.06-tags/libs/users-api/project.json#L5 }
  "prefix": "lib",
  "tags": ["type:lib", "lib:api"],
  "projectType": "library",
  "targets": {
    "test": {
      "executor": "@nx/jest:jest",
```

For `libs/users-http`:

```json { actualFilename=../../../manuscript/code/06.06-tags/libs/users-http/project.json endLine=10 startLine=5 statedFilename=libs/users-http/project.json url=https&#x3A;//gitlab.com/fullstackio/books/building-angular-applications-with-nx/module_07/lesson_07.06/.../../manuscript/code/06.06-tags/libs/users-http/project.json#L5 }
  "prefix": "lib",
  "tags": ["lib:ui", "lib:http"],
  "projectType": "library",
  "targets": {
    "test": {
      "executor": "@nx/jest:jest",
```

galczo5

Why defining a target architecture may be an important step of the migration process

Tips. Target architecture

I won't convince you to switch from one architecture to another because it's

We are not going to describe the advantages or disadvantages of architectures.

Every project is different and the architecture that works on my project might

What's more, every project that I worked on had a different approach and a bit

Knowledge about the context, customer, team needs is the key to successful code

In this lesson, we'll focus on edX features that will help you organize your

and libraries in the way that suits almost all possible architectures.

The common problem is that no matter which architecture you're using, almost

rules and you need to enforce them. For example, in domain-driven design, you

the domain so your components will use only methods exposed by API services.

These rules are often related to code decomposition.

You just want to be sure that some classes will not import other classes

huge mess. In case of edX, we can make sure that programmers will not be able

libraries that shouldn't be used in other libraries. For example, you don't

developers to import parts of applications in other applications. It makes

depend on each other and it's not a good idea. So edX gives you something

You can tag your libraries and then use these tags to create rules. For example

tags like type app or type library. So you can say that this project is an app,

in a library. You can even add more tags like library UI or library API to say

will contain only UI logic, this project will contain API logic and so on. So

some code and I will show you in practice how it looks like. On the screen at

you see all the comments I use to generate a new application. So my application

application and three libraries, users UI, users API and users HTTP. And in my

I'm going to create a few decks. So first of all, type app for applications,

and then library specific stacks, leap UI for UI components, leap API for API

leap HTTP for HTTP layer of my application. So in my design, apps can depend

Libraries can depend on other libraries. UI libraries can be used in

API libraries can be used in UI libraries or applications and HTTP libraries

UI component libraries and API libraries. So as you can see, we have some rules

Let generate the code and I will show you how to configure an X to respect

All right, as you can see, I have my application generated, I have my app and

every single app and library contain project.json file. And let's start with

As you can see in seventh line, you have a right of text and we can specify

tags we want. So for my app, I'm going to use only one tag, type app. Then let

UI. And once again, let's open project.json, we have tags. And I'm going to add

library and library UI. Next one is users API. Let's open project.json and let

type library and library API. And the last one is users HTTP. Let's add tag

All right, so we have our attacks configured, but how to use them. So let's

tags can be used by another tax. And to do this, we need to open as linked RC

linked configuration. And as you can see, we have a role called NX slash and

And you can use this as the role to model your architecture. As you can see, we

constraints here. So let's configure the first rule that apps can depend only

this, I'm setting an object with source tag type app. And it only depends on

type library. So all the project that have type app can depend only on type

going to have a dependency between one project with type app to another project

it will throw an as linked error. The next rule that we want to specify is that

depend on other libraries. And it will be similar to the role we have at the

So source tag type library, and it can depend only on other type library. And

trick, we say that libraries cannot depend on other apps. All right, so now let

our library specific decks. So for our library UI library API and library HTTP.

our library UI can depend only on library HTTP library API and other library UI

Then library API can depend only on library HTTP or other library API. And the

Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

Masterclasses

Tutorials

Fullstack React with TypeScript