3.3. Data Oriented Architecture

Данные важнее кода.

Data Oriented Architecture – подход, который ставит работу с Данными на первое место

1. Не создавайте абстракций поверх структур данных хранилища

2. Операции над источником данных приоритетнее бизнес-логики

i. Не создавайте абстракций

class UserModel {
	id: number // Это поле лежит в таблице `user` основной базы
	profile: ProfileModel // В БД Profile не будет частью User, а лишь связью через foreign key на Profile
	email: string // Это поле вообще хранится в отдельной системе
}

class ProfileModel {
	id: number // Это поле лежит в таблице `profile` основной базы
	age: number // Это поле лежит в таблице `profile` основной базы
	firstName: string // А это поле лежит в таблице `profile` легаси базы
	user: UserModel // User не является частью Profile, а связан с ним по полю `userId`
}

type ChangeUserProfileRequest = {
	data: Profile // не будем описывать нужные поля, а просто восопльзуемся уже описанной моделью Profile
}

Идея DoA, в том, чтобы работать с нашими данными так, как они выглядят в оригинале, не создавая лишний абстракций поверх:

// # Таблицы из основной БД
type UserTable = {
	id: number // В БД это будет Serial
}

type ProfileTable = {
	id: number
	legacyProfileId: string
	userId: number
	age: number
}
 
// # Таблицы из легаси БД
type OldProfileTable = {
	id: string
	firstName: string
}

// # Данные из сторонней системы аутентификации (Auth0)
type GetUserDataRequest = {
	id: string
	userId: number
	email: string
}

type ChangeUserProfileRequest = {
	data: {
		firstName: string
		age: number
		userId: number
	}
}

А если нам неудобно работать с исходной структурой?

1. Вы можете расширять типы, пока это расширение обратносовместимо.

2. Вы можете добавлять расчитываемые поля (computed fields)

3. Если вы используете другую сущность, то используйте ее полностью

type PositiveNumber = BrandedType<number, "PositiveNumber"> // О брендированных типах поговорим позже

const PositiveNumber = {
  ofNumber: (val: number) => {
    if (val < 0) {
      throw new Error()
    }
    return val
  }
}

type Profile = ProfileTable & {
	age: PositiveNumber // # Пример расширения уже существующего типа
}

type UserWithProfile = {
	user: UserTable // Пример полного использовальния уже существующей структуры в БД
	profiles: ProfileTable[] // Пример полного использовальния уже существующей структуры в БД
  profileCount: number // Пример расчитываемого поля
}

ii. Операции над источником данных приоритетнее бизнес-логики

1. Невозможность использования специфичных функций вашего источника данных (если уж мы сделали абстракцию, то использовать какую-нибудь особенную возможность PostgreSQL – это уже привязываться к ее коду)

2. Невозможность низкоуровневых оптимизаций работы с источником данных. Любая оптимизация потребует использования более конкретных операций над источником данных, но мы нам “нельзя” его прокидывать туда, куда нужно.

3. Трата кучи времени на создание интерфейсов и абстракций, которые по итогу очень часть или не будут достаточно абстрагировать источник данных (например, чтобы его заменить), дадут вышеописанные проблемы, так еще и будут вызывать по одному методу друг друга (как часто я видел, что Controller, вызывает метод Adapter, который в свою очередь просто дергает UseCase, который ничего не делает кроме как вызвать Repository… и так 90% кодовой базы…)

Так вот, идея DOA ровно противоположна: не создавайте дополнительных слоев, используйте работу с вашими источниками данных где угодно и как угодно.

Что дальше?