UML stands for Unified Modeling Language. It was created to facilitate the communication and documentation of IT designs and architectures. A UML sequence diagram is a type of dynamic behavior diagram that illustrates how objects interact and the sequence of those interactions.

While a UML class diagram depicts the structure of classes and interfaces, a sequence diagram focuses on the processes and interactions between objects or within an object. However, defining a precise sequence diagram can be more complex. It typically contains more elements than a class diagram. As with any tool, it's important to use the sequence diagram for its intended purpose.

For slightly more complex cases, implementing a sequence diagram may require significant effort. Challenges arise when you need to update the diagram, such as adding an object, actor, or new messages in the middle. For these situations, I recommend using DSL-based tools to implement and manage the diagram effectively.

**When to use ✔️**

- ✔️ Planning refactoring

- ✔️ Describing dynamic behavior

- ✔️ Describing processes

- ✔️ Network topology

- ✔️ Event driven designs

- 😐 Identifying relationships

**When to avoid ❌**

- ❌ Designing system architecture

- ❌ Documenting the system architecture

- ❌ Database schema design

- ❌ Large systems

- ❌ Static structure

- ❌ Exposing too much implementation details

UML - Sequence Diagram

UML stands for Unified Modeling Language. It was created to communicate and document IT designs and architecture. UML class diagram is a static structure diagram, that describes interfaces, classes, attributes and methods, and relationships between.

What I like about UML class diagram, that the complexity in the diagram itself is optional. You can omit the attributes and methods if you think, that they will not serve the purpose of conducting the information that you want to share with this chart. In other situation, you can be very explicit defining all attributes, relations and cardinalities if the problem domain is small and chart can be explicit. With UML class diagram you can create a documentation or design artifact, that will be better that 100 words and better than code. Because of ease of use UML class diagram can be used as a bridge communicating complex designs to a non technical users, stakeholders.

**When to use ✔️**

- ✔️ Designing system architecture

- ✔️ Documenting the system architecture

- ✔️ Database schema design

- ✔️ Identifying relationships

- ✔️ Planning refactoring

**When to avoid ❌**

- ❌ Describing dynamic behavior

- ❌ Describing processes

- ❌ Network topology

- ❌ Large systems

- ❌ Event driven designs

Code form the charts:

```typescript
export class Customer {
    constructor(
        public customerId: number,
        public name: string
        ) {}
}
export interface Order {
     orderId: number,
     totalAmount: number,
     customer: Customer
}
export abstract class BaseOrder implements Order {
    constructor(
        public orderId: number,
        public totalAmount: number,
        public customer: Customer
        ) {}
}
export class BookOrder extends BaseOrder {
    constructor(
        orderId: number,
        totalAmount: number,
        customer: Customer,
        private isbn: string

    ) {
        super(orderId, totalAmount, customer);
    }
}
export class Employee {
    private name: string;

    constructor(employeeId: number, name: string) {
        this.name = name;
    }
    processOrder(order: Order): void {}
}
export class Department {
    constructor(
        employees: Employee[]
    ) {}
}
export class OrganizationalStructure {
    constructor(
        departments: Department[]
    ) {}
}
```

UML - Class Diagram

Domain driven design (DDD) is a methodology for designing software with a focus on the domain. DDD is one of the main practices used in the microservices development. I'll cover 3 main concepts of the DDD:

- Ubiquitous Language - use the same language/terms in the code and in the business. This allows programmers to talk to the business people without misinterpretation.

- Aggregate - Related objects, that form a consistency boundary and are treated as a single unit. For example in the "Customer" domain, "Address" is an aggregate.

> An aggregate is a cluster of associated objects that we treat as a unit for the purpose of data changes. Each aggregate has a root and a boundary. The boundary defines what is inside the aggregate. The root is a single, specific ENTITY contained in the aggregate.

_Domain Driven Design, Eric Evans_

- Bounded Context - a logical and physical boundary around a coherent and consistent domain or subdomain

What if you already have a domain and want to slice it to migrate from the monolith to the microservices, for example? You can do this using these patterns:

- Volatility - split by the performance sensitive parts

- Data - split by usage or restrictions on the data

- Technology - split by a technology stack

- Organizational - align with the company organizational structure

_Microservices, 2nd edition by Sam Newman_