DRD Architecture

QUAK developed DRD architecture (DTO's Repository Domain) for SPA frontend.

What is DRD?

Example of DRD Architecture for users feature:

Graph

Description

DRD split business logic from presentation layer/use case. DRD is framework agnostic architecture that can be used in any programming language.

DRD focus on models that have business bahavior and proper abstraction for managing data from BACKEND → FRONTEND.

DRD makes views creation simple, secure and fast.

Why?

• Easy to maintain - you can easily change field names in translations layer (DTO) and it will be automatically changed in all other layers, etc.
• Easy to test - you can easily test each layer because it is regulary single responsibility cases
• Easy to understand - you can easily understand what is going on in each layer
• Easy to scale - you can easily add any new views once you created proper foundation
• Beautiful models - finally you can have beautiful models with methods and not only data
• Reactivity - you can easily react to any change in store, your views are always up to date and way simpler

When?

• When you have frontend client - DRD Architecture makes sense only if you have separate frontend client, like SPA or mobile app
• Complexity - DRD Architecture makes sense for small and enterprise projects, but not for simple projects (let HTML and JS/TS be the king in simple apps)

Example

Example common feature: users

  type UserID = string;
  type Role = "admin" | "user" | "moderator";

Create User usage

DI setup

const userRepo = new UserRepositoryService();
const userCreationService = new UserCreationService(new UserCreationPolicy(), userRepo);

Create User

const user = await User.create('John', ['user', 'moderator'], userCreationService);

Use decorator pattern

In case when you want to add some additional logic to your model, you can use decorator pattern.

class SendEmailOnUserCreation implements CreateUser {
  constructor(
    private userCreationService: CreateUser,
    private emailService: EmailService,
  ) {}
 
  async createUser(username: string, roles: Role[]): Promise<User> {
    const user = await this.userCreationService.createUser(username, roles);
    await this.emailService.sendEmail(user);
    return user;
  }
}

When you need another decorator, you can easily add it.

class NotifyAdminOnUserCreation implements CreateUser {
  constructor(
    private userCreationService: CreateUser,
    private adminService: AdminService,
  ) {}
 
  async createUser(username: string, roles: Role[]): Promise<User> {
    const user = await this.userCreationService.createUser(username, roles);
    await this.adminService.notifyAdmin(user);
    return user;
  }
}

Then simply use it.

const userRepo = new UserRepositoryService();
const createUserWithAnEmail = new SendEmailOnUserCreation(
    userCreationService, new EmailService()
);
 
const user = await new NotifyAdminOnUserCreation(createUserWithAnEmail, new AdminService())
    .createUser('login', ['moderator']);

Testing

Since every layer is separated, you can easily test each layer.

describe('UserCreationService', () => {
  it('should create user', async () => {
    const userRepo = new TestUserRepositoryService(); // mocked repo
    const userCreationService = new UserCreationService(new UserCreationPolicy(), userRepo);
    const user = await userCreationService.createUser('John', ['user', 'moderator']);
    expect(user).toBeInstanceOf(User);
  });
});

This is it! Now you can use your models in views and use cases.

READ

Latest readings

• Readings are sites which will help you with detailed

• information about given topic. Read latest ones from Learn.