DEV Community: Bohdan Turyk

Architecture Is Even More Essential in the Age of AI

Bohdan Turyk — Mon, 13 Jul 2026 11:53:32 +0000

AI tools are changing the way we write software: code is becoming cheap and nearly instant. What hasn't changed is that systems still need to be understood, maintained, and grown. To me, that makes software architecture — the well-known fundamentals like SOLID, layered architecture, high cohesion and low coupling, design patterns, etc. — what keeps a system manageable and moving fast. It's something worth thinking about from day one.

These fundamentals have been around for decades and proved their effectiveness long before AI entered the picture. In the age of AI, they seem to play an even more important role.

Why it matters

AI can generate any type of code, often faster than we can read it. Keeping the system manageable is becoming the real bottleneck — and without structure, a codebase can drift out of shape quicker than ever. The fundamentals can work as guardrails here: a proven, shared language that keeps the system in a form we can still understand and direct.

Following these principles helps keep a system manageable and understandable, and brings the qualities that come with that — flexibility, extensibility, stability. These are what help an application move faster and stay robust: a well-structured system can be changed quickly and with confidence, so we keep moving fast largely because of architecture, not despite it.

Takeaway

Code is getting cheap; understanding it and keeping it under control is becoming the expensive part. Architecture keeps a system in shape — which makes it worth treating as a day-one concern.

The code can be generated; the structure is still ours to shape.

Anticorruption Layer in a Modular Application

Bohdan Turyk — Wed, 19 Mar 2025 08:26:21 +0000

In this article, I would like to describe an example of an anticorruption layer for modules based on a layered architecture. Hopefully, this will be useful to someone.

To keep the article concise, I will try to be short in explanations/examples. Below, you can find a link to a more detailed example of this approach. And, of course, if you have any questions or thoughts, feel free to use the comments section. 😉

So, let's get started. First, we will see a very short overview of layered architecture. Then, we will review an example of modules based on this architecture and identify issues with communication. After that, we will try to address these issues using the Anticorruption layer.

Short Overview of Layered Architecture

The idea behind layered architecture is straightforward. Application logic is structured as a set of layers, ordered by importance (the deeper the layer, the more important it is) that follow dependency rule. In this article, we will use the Domain, Application, and Infrastructure layers. It's quite similar to Clean Architecture.
Here is illustration of it:

The Domain layer contains entities and services with significant business rules (e.g., the Order entity).
The Application layer contains use cases (services) that the module offers (e.g., CreateOrderService).
The Infrastructure layer contains implementations of interfaces defined in the inner layers (low-level details) (e.g., OrderRepository).

Important thing here is the dependency rule (arrows on the screen). Dependencies should only be directed inward. This means that a layer should not depend on or be aware of outer layers. In practice, this usually means that if you need to call a service from an outer layer, you should define an interface within the current layer that specifies the required functionality. However, the implementation should reside in the outer layer (dependency inversion principle).

Modules

Let’s go a bit further and assume we have two modules, User and Notification, that follow this architecture. The Notification module is responsible for sending notifications to a user, while the User module provides notification settings for a user.

According to this architecture, the structure of these modules could be as follows:

Module
├── Notification
│   ├── Application
│   │   ├── CreateNotificationUseCase.ts
│   ├── Domain
│   └── Infrastructure
└── User
    ├── Application
    │   ├── ProvideNotificationSettingsUseCase.ts
    ├── Domain
    └── Infrastructure

To send a notification (handled by the Notification module), we need to retrieve the user's notification settings (provided by the User module).
Strictly speaking, the CreateNotificationUseCase needs to call ProvideNotificationSettingsUseCase. However, doing this directly introduces several issues:

Violation of the dependency rule — the Application layer "knows" about something that doesn't belong to it (not even to its own module).
Uncontrolled dependencies, which become difficult to manage.

In simple terms, the Notification module becomes corrupted by the User module.

So, what would be a better approach?

Anticorruption layer

We can define clear communication rules for these two modules and encapsulate them in an Anticorruption layer (actually sublayer, will see shortly).

According to layered architecture principles, the Domain and Application layers contain the core business logic of a module and should not include low-level implementation details (such as database queries). Let's stick to this principle.

To achieve this, we will create an interface in the Application layer that provides the required functionality (retrieving notification settings) for the current layer. The implementation of this interface will reside in the Infrastructure layer of this module, treating it as a low-level detail.

Additionally, to maintain better control over such dependencies, we will place them in an Anticorruption folder/sublayer within the Infrastructure layer. Each module will have its own dedicated folder within this sublayer. This approach makes dependencies between modules explicit.

Now, let's look at the updated module structure (pay attention to the ADDED sections):

Module
├── Notification
│   ├── Application
│   │   ├── CreateNotificationUseCase.ts
│   │   └── UserNotificationsSettingsProviderInterface.ts # ADDED - defines required functionality for this layer
│   ├── Domain
│   └── Infrastructure
│       └── Anticorruption  # ADDED
│           └── User # Name of the module this one depends on
│               └── UserNotificationsSettingsProvider.ts # Implementation of the interface defined in the Application layer
└── User
    ├── Application
    │   ├── ProvideNotificationSettingsUseCase.ts
    ├── Domain
    └── Infrastructure

So far, so good. Now, let’s take a closer look at the logic within these layers, starting with the Application layer of the Notification module.

// src/Module/Notification/Application/CreateNotificationUseCase.ts

export class CreateNotificationUseCase {
  constructor(
    private readonly userNotificationsSettingsProvider: UserNotificationsSettingsProviderInterface,
  ) {}

  async createNotification(payload: NotificationPayload): Promise<void> {
    const settings = await this.userNotificationsSettingsProvider.getSettings(
      payload.userUuid,
    );
    // todo send notification based on settings
  }
}

// src/Module/Notification/Application/UserNotificationsSettingsProviderInterface.ts

export interface UserNotificationsSettingsProviderInterface {
  getSettings(userUuid: string): Promise<NotificationsSettings>;
}

As seen in the example above, we have not introduced any direct dependencies on the User module within the Application layer. This is great because this layer should not depend on outer layers (following the dependency rule).

Instead, we created the UserNotificationsSettingsProviderInterface interface, which is sufficient for CreateNotificationUseCase. This inverts the dependency.

Now, let’s see how this interface is implemented in the Anticorruption layer:

// src/Module/Notification/Infrastructure/Anticorruption/User/UserNotificationsSettingsProvider.ts

import { UserNotificationsSettingsProviderInterface } from '@Module/Notification/Application/UserNotificationsSettingsProviderInterface';
import { ProvideNotificationSettingsUseCase } from '@Module/User/Application/ProvideNotificationSettingsUseCase';

export class UserNotificationsSettingsProvider
  implements UserNotificationsSettingsProviderInterface
{
  constructor(
    // inject service from User module
    private readonly provideNotificationSettingsUseCase: ProvideNotificationSettingsUseCase,
  ) {}

  async getSettings(userUuid: string): Promise<NotificationsSettings> {
    const userNotificationsSettings =
      await this.provideNotificationSettingsUseCase.getUserNotificationsSettings(
        userUuid,
      );

    return {
      ...userNotificationsSettings,
    };
  }
}

As you can see, we injected ProvideNotificationSettingsUseCase from the User module. That's okay because this implementation resides in the Infrastructure layer.

This is the only place where communication between modules happens. The communication looks manageable, clear, and does not break the dependency rule.

You can find a more detailed version of this approach in my GitHub repository:
https://github.com/benedya/nestjs-layered-architecture
Additionally, this repository includes preconfigured ESLint rules that help track dependency violations between layers.

Domain vs Application Services: what is the difference

Bohdan Turyk — Sat, 22 Feb 2025 05:31:12 +0000

I've been learning and applying Domain-Driven Design (DDD) principles for a few years, and I often struggle with distinguishing between domain and application services. In this article, I’d like to share some observations and thoughts based on my experience. Hopefully, you’ll find something useful here!

Approach

I’ll first explore services in a complex domain and then in a simple one. After that, I’ll summarize my thoughts.

A Complex Domain

It seems easier to separate domain and application services in a complex domain. Let’s illustrate this with an example.

Imagine a banking application where we need logic to transfer money from one account to another. Below is a simplified snippet demonstrating possible application and domain services for that purpose:

// src/Domain/Entity/Account.ts

class Account {
    balance: number;
}

// src/Domain/Service/MoneyTransferDomainService.ts

class MoneyTransferDomainService {
    async transferMoney(fromAccount: Account, toAccount: Account, amount: number): Promise<void> {
        if (fromAccount.balance < amount) {
            throw new Error('Insufficient funds.');
        }

        fromAccount.balance -= amount;
        toAccount.balance += amount;
    }
}

// src/Application/MoneyTransferApplicationService.ts

class MoneyTransferApplicationService {
    async transferMoney(fromAccountId: number, toAccountId: number, amount: number) {
        const fromAccount = await this.accountRepository.findOneById(fromAccountId);
        const toAccount = await this.accountRepository.findOneById(toAccountId);

        if (!fromAccount) {
            throw new Error(`Account with id "${fromAccountId}" not found`);
        }

        if (!toAccount) {
            throw new Error(`Account with id "${toAccountId}" not found`);
        }

        await this.moneyTransferDomainService.transferMoney(fromAccount, toAccount, amount);
    }
}

In this example, the MoneyTransferDomainService encapsulates a crucial business rule: moving money between accounts. It belongs in the domain layer because it represents core business logic. Meanwhile, the MoneyTransferApplicationService acts as a coordinator, retrieving the necessary entities and delegating the core transfer logic to the domain service.

This separation makes sense. We have a main part that belongs to domain layer and a secondary that belongs to application layer. Let's explore at a few alternatives applicable to this example.

Possible Alternatives

1. Placing the logic inside the `Account` entity

This could lead to bloated entities (a “god class”).
It sometimes unclear which entity should contain the logic when multiple entities are involved. In a more complex example with PersonalAccount and BusinessAccount, it would be harder to decide where to place this logic.

2. Moving the logic to `MoneyTransferApplicationService`

This would cause domain logic to leak into the application layer.
The application layer would gain more responsibilities, some of which may seem redundant.

Hints for Identifying a Domain Service

The logic is crucial for the business.
The logic involves interactions between multiple entities.

A Simple Domain

Now, let’s consider an example from a simpler domain. Suppose we have a user management component where we need to update a User entity. Here’s a relevant snippet:

// src/Domain/Entity/User.ts

class User {
    name: string;
    email: string;
}

// src/Application/UpdateUserApplicationService.ts

class UpdateUserApplicationService {
    async update(id: number, name: string, email: string) {
        const user = await this.userRepository.findOneById(id);

        if (!user) {
            throw new Error(`User with id "${id}" not found`);
        }

        user.name = name;
        user.email = email;
    }
}

Here, we only have an application service, which looks okay since updating a user’s details does’t look like a complex business rules that should be encapsulated in the heart of the application.

If there is no significant business rules it's hard to find reasons moving such logic into domain layer. In such cases having only application services look enough.

A Few Final Thoughts

So, what’s the difference then? It's still a tough question for me. But one guideline seems clear: domain services should encapsulate significant business rules. The more essential a piece of logic is to the business, the more it navigates toward the domain layer. Conversely, if the logic is less central to the business or mainly coordinates processes, it tends to the application layer. However, this distinction isn’t always straightforward.

At times, I question whether creating domain services is even necessary. In such cases, Clean Architecture principles can be appealing. Instead of debating which layer a piece of logic belongs to, Clean Architecture offers a clear answer: it should be placed within a use case.

Additional Resources

If you’d like to dive deeper into these topics, here are some useful references:

Domain-Driven Design by Eric Evans (Chapter Five: A Model Expressed in Software – Services)
Clean Architecture by Robert C. Martin (Part V: Architecture, Chapter 22: The Clean Architecture – Use Cases)
Domain-Driven Design vs. Clean Architecture – Khalil Stemmler

This is my first post—hope you found it helpful! :)