The complete guide to designing, developing, testing, and deploying enterprise applications with Angular

Angular Applications Architecture

Requirements and FAQs

Code style guide

Introduction

Start from the domain

Software architecture for Front-end

Domain, design, develop

Workspaces scenarios

Applications and Libraries

Mono repository multi project

Domain boundary with plain TypeScript

Application details with Angular

Presentational details with Angular

Domain boundary and application details

Testing big Angular solutions with ease

Narrow tests for business logic

Visual tests for the presentation layer

Wide tests for the user experience

Testing since the beginning

Configuration environment and tokens

Instrumentation measuring and logging

Security authentication and authorization

Core generic infrastructure

A library for your shared UI vocabulary

A set of basic atomic elements

Some generic composed blocks

User interface, a design system foundation

Reactive stores with Signals

API access as a commodity

Interceptors for the dirty job

Data stores, reactive access, and persistence

Features come in routes to pages

Anatomy of a Page control flow and services

Different levels of state management

Routes and pages

In this course we teach you how to design, develop, ane deploy enterprise level Angular Applications the right way. Despite the fact that Angular is an opinionated framework, specially suited to build large solutions, it requires a deep knowledge to take decisions at every step.

In almost 30 lessons we cover how to choose and use the correct tools, how to structure an application that scales and how to code some intricate solutions to common problems. It's a long course/book and comes with a complete working codebase fully tested.

It is taught by Alberto Basalo who has been working, advising, and training multinational corporations, banks, and public administrations in Angular for years.

The complete guide to design, develop, test, and deploy enterprise applications with Angular

How to design, develop and deploy big enterprise applications with Angular.

Best practices to organize your code in small reusable libraries.

Application of reactive flow patterns for better user and developer speed.

Leverage the latest Angular version features like stand-alone components.

Common functionality for any application ready to use.

It is time to start writing some code; there is no better place in our code than the application domain.

, where standard interfaces are defined, we will climb to 

 for our first use case: create a document. 

from the domain boundary to the application layer

. Finally, we will spot the ports and adapters where the domain limits encounter the framework.

During the journey, we will also find beneficial design patterns for building robust and maintainable applications.

Follow this diagram as a road map to understand the application's structure and focus on the packages we will work on in this lesson.

, we saw that the application domain must be divided into functional subdomains to address them independently. Each one will surely share some common features with the others, and that's where the need for a shared domain appears.

, at this level, we are in the abyss of the application. No dependencies with external libraries or frameworks are allowed here. On the contrary, here, we will define the interfaces and utilities used in the whole domain and the application layers for the complete solution.

The types are the contracts that define the information of the domain entities and the data flow with the application layer. 

 is a structure that moves data between processes, such as a client and a server, or between layers inside an application.

When used to be persisted, it needs an identifier for later search. This unique property is what the next type ensures.

/**
 * Unique Identifier type.
 */
export type Id = string | number;

/**
 * DTO persistance base type.
 */
export type DTO = {
  /** Unique Identifier */
  id: Id;
};
/**
 * A default DTO object to avoid null checks.
 */
export const NULL_DTO = {
  id: '',
};

Use cases are the main business processes executed by the application. It could be simple functions or methods in a class, but I implemented them following the 

 design pattern. For this, I need an executor method that returns a predictable result. Nothing is better than an interface guaranteeing that all commands are executed similarly.

/**
 * UseCase interface. Defines the execution of a command pattern.
 * Is an asynchronous operation that can produce a DTO, an array of DTOs or nothing.
 * @param T The DTO type.
 **/
export interface UseCase<T extends DTO | DTO[] | void> {
  /** The argument needed during execution */
  payload: object;
  /** executes the asynchronous command and returns something or void */
  execute(): Promise<T>;
}

 We are used to programming business actions as methods of a class. This pattern elevates them to a higher category and dedicates a class for each business activity. In this way, the commands can be audited and reused in different contexts; even in some cases, you can override their effects.

This section is the mixed bag of the application. Here are the utilities used on the domain that do not belong to any particular subdomain. You can find the code in the 

new-docs\libs\shared\domain\src\lib\utils

 folder. Here is a non-complete list of some of them.

A slug generator that produces a URL-friendly string from a given text is also coded at the 

 function. You can use the result to access a document by its title, people's names, or any other text used in a URL as a unique identifier.

We have utilities to parse and manipulate text strings like 

, which are used along the code base. As an anticipated tip, I will say that any complex Angular pipe should delegate its implementation to pure functions that are easy to test. 

The same goes for time helpers. Or numbers, or whatever function you think will be used across the solution and has no extra dependency.

---
title: Domain boundary with plain TypeScript
isPublicLesson: false
useMdx: true
---

# Domain boundary with plain TypeScript.

### What you will learn in this lesson.

It is time to start writing some code; there is no better place in our code than the application domain.

Beginning from _the shared domain_, where standard interfaces are defined, we will climb to _the editor section_ for our first use case: create a document. 

We will go inside out _from the domain boundary to the application layer_. Finally, we will spot the ports and adapters where the domain limits encounter the framework.

During the journey, we will also find beneficial design patterns for building robust and maintainable applications.

Follow this diagram as a road map to understand the application's structure and focus on the packages we will work on in this lesson.

![The domain for the createDocument use case](https://d2uusema5elisf.cloudfront.net/courses/angular-applications-architecture/module_04/lesson_04.01/public/create-document.domain.png)

## The Shared Domain.

When we studied **DDD analysis**, we saw that the application domain must be divided into functional subdomains to address them independently. Each one will surely share some common features with the others, and that's where the need for a shared domain appears.

Also known as **the Kernel layer**, at this level, we are in the abyss of the application. No dependencies with external libraries or frameworks are allowed here. On the contrary, here, we will define the interfaces and utilities used in the whole domain and the application layers for the complete solution.

### The base Models:

The types are the contracts that define the information of the domain entities and the data flow with the application layer. 

-   `DTO`

The _Data Transfer Object_ is a structure that moves data between processes, such as a client and a server, or between layers inside an application.

When used to be persisted, it needs an identifier for later search. This unique property is what the next type ensures.

```typescript
/**
 * Unique Identifier type.
 */
export type Id = string | number;

/**
 * DTO persistance base type.
 */
export type DTO = {
  /** Unique Identifier */
  id: Id;
};
/**
 * A default DTO object to avoid null checks.
 */
export const NULL_DTO = {
  id: '',
};
```

-   `UseCase`

Use cases are the main business processes executed by the application. It could be simple functions or methods in a class, but I implemented them following the _Command_ design pattern. For this, I need an executor method that returns a predictable result. Nothing is better than an interface guaranteeing that all commands are executed similarly.

```typescript
/**
 * UseCase interface. Defines the execution of a command pattern.
 * Is an asynchronous operation that can produce a DTO, an array of DTOs or nothing.
 * @param T The DTO type.
 **/
export interface UseCase<T extends DTO | DTO[] | void> {
  /** The argument needed during execution */
  payload: object;
  /** executes the asynchronous command and returns something or void */
  execute(): Promise<T>;
}
```

:::tip
  **Command pattern.** We are used to programming business actions as methods of a class. This pattern elevates them to a higher category and dedicates a class for each business activity. In this way, the commands can be audited and reused in different contexts; even in some cases, you can override their effects.
:::

### Utils:

This section is the mixed bag of the application. Here are the utilities used on the domain that do not belong to any particular subdomain. You can find the code in the `new-docs\libs\shared\domain\src\lib\utils` folder. Here is a non-complete list of some of them.

-   `identifiers`

A slug generator that produces a URL-friendly string from a given text is also coded at the `getSlug(source)` function. You can use the result to access a document by its title, people's names, or any other text used in a URL as a unique identifier.

-   `text` and `time`

We have utilities to parse and manipulate text strings like `charCount(content)` or `minutesToRead(content)`, which are used along the code base. As an anticipated tip, I will say that any complex Angular pipe should delegate its implementation to pure functions that are easy to test. 

The same goes for time helpers. Or numbers, or whatever function you think will be used across the solution and has no extra dependency.

:::tip
**Tests.** There will be a chapter devoted to testing. Meanwhile, you can find the unit tests for these utilities right next to them in the source code. To run them, execute `npm run shared-domain:test` in the project's root folder.
:::

## The Editor domain.

Take the stairs; we’re going up one floor for a concrete implementation of those shared interfaces and use the standard utilities we have just coded. The editor domain has our main business features. It is the place where the user will create, edit, and delete documents. And making a document will be our first use case to exploit all the shared domain artifacts.

Following any clean architecture, we have that each feature domain can be seen as an onion with several inner layers.  One rule must be obeyed: external layers depend on the inner ones.

At the innermost layer, **the Core layer**, we must create some artifact that ensures data integrity: the entity. Covering the nut is the use case layer. The surface of the core will talk with the application layer through interfaces. (Remember, no upstream dependency allowed). Data in and out is encapsulated in Plain Old Objects, known by their main utility as Data Transfer Objects.

### Business rules with Entities:

The entity is a `class` that wraps data objects and implements the business rules that guarantee the integrity of the information.  In this case, we will validate the document's title and author as the invariants of a well-constructed document. We also check content changes and any other stuff related to the document here. Here you have an excerpt of its content.

-   `DocumentEntity`

```typescript
/**
 * Document Entity, to create, read, update and delete documents
 * @description Ensures business rules and invariants
 */
export class DocumentEntity implements DocumentActions {
  /** Document main data and identification */
  get header(): DocumentHeaderDTO {
    return { ...this.#header };
  }
  #header: DocumentHeaderDTO = NULL_DOCUMENT_HEADER_DTO;
  /** Document content */
  get content(): DocumentContentDTO {
    return { ...this.#content };
  }
  #content: DocumentContentDTO = NULL_DOCUMENT_CONTENT_DTO;
  /** Document metrics */
  get metric(): DocumentMetricDTO {
    return { ...this.#metric };
  }
  #metric: DocumentMetricDTO = NULL_DOCUMENT_METRIC_DTO;