От хаоса к структуре: как FEOD помогает упорядочить архитектуру фронтенд-приложений

Интересный подход, явно проще для понимания, чем FSD)

Не совсем понятны правила импорта между модулями. Допустима ли ситуация, когда один модуль импортирует через public API что-то из подмодулей другого модуля? Например, модулю Order что-то понадобилось из подмодуль User/Profile

Архитектура фронтенда. Навеяно болью от использования FSD

Тут скорее вопрос, как превратить JSON в классы бизнес-логики :)

Нам приходит задача с бэкенда в формате «анемичной» модели. Мы хотим ее расширить, превратить в модель, которая имеет внутренние механизмы для сохранения инвариантов.

Для этого в репозитория/коннекторе вызываем конструктор класса Task. И вот на этом этапе у меня вопрос: может ли конструктор Task использовать конструкторы User и Files для создания своего класса или правильнее будет создать специальные классы для задачи (TaskAuthor, TaskFile и пр.)?

// task.repository.ts

class TaskRepostirory {
  fetchTack(id: string): Task {
    const data = axios.get(`/tasks/${id}`);
    
    // Тут может дополнительно написан адаптер
    
    const model = new Task(data);
    return model
  }
}

// task.model.ts

class Task {
  constructor(data: TaskData) {
    this.id = data.id;
    this.title = data.title;
    this.description = data.description;

    // Не появляется ли здесь связаннность,
    // которую мы бы не хотели?
    this.author = new User(data.author);
    this.performer = new User(data.performer);
    this.reviewer = new User(data.reviewer);
    this.files = data.files.map(m => new File(m))
  }
}

Ну и в модели могут быть value objects типа email, phone, содержащие в себе доп. валидацию, методы для форматирования и пр.

Архитектура фронтенда. Навеяно болью от использования FSD

Возможно, не совсем точно выразился :) Взаимодействие между API, моделью и UI для меня выглядит вполне логично.

Мне интересно, как идет взаимодействие между связанными сущностями. На бэкенде есть таблицы Tasks, Users, Files. При запросе конкретной задачи мы получаем следующие данные:

{
  "id": 1,
  "title": "Моя задача",
  "description": "Описание задачи",
  "author": {
    "name": "Иванов Иван Иванович",
    "position": "Директор",
  },
  "files": [{
    "title": "document.docx",
    "size": 1234,
    // Прочие поля
  }],
}

Наша модель является классом, соответственно, как нам в конструкторе модели Task использовать эти сущности? Насколько корректно делать так, не вызывает ли это лишней связанности между моделями?

import { User } from '@/domain/user'
import { UUID, File } from '@/domain/shared'

class Task {
  id: UUID,
  title: string,
  description: string,
  author: User,
  reviewer: User,
  performer: User,
  files: File[],
}

Или лучше под вместо моделей User и File использовать TaskUser и TaskFile, которые будут лежать вместе с Task, хранить специфическую для задачи логику, и не будут доступны через публичный интерфейс?

import { UUID, File } from '@/domain/shared'
import { TaskAuthor } from './task-author'
import { TaskReviewer } from './task-reviewer'
import { TaskPerformer } from './task-performer'
import { TaskFile } from './task-file'

class Task {
  id: UUID,
  title: string,
  description: string,
  author: TaskAuthor,
  reviewer: TaskReviewer,
  performer: TaskPerformer,
  files: TaskFile[],
}

class TaksFile {
  canDelete(task, user) {
    // какая-то логика
  }
}

Архитектура фронтенда. Навеяно болью от использования FSD

Добрый день! Очень понравилась статья, сам думал в эту сторону, после прочтения синей книги. Подскажите, как вы видите взаимодействие между сущностями? Вроде как в DDD для тесно связанных между собой сущностей используются агрегаторы.

Возьмем такой кейс: есть канбан-доска с задачами. У задачи есть статусы, описание, комментарии, прикрепленные файлы. Для задачи может быть назначен исполнитель, автор и наблюдатель.

Бизнесом закладываются определенные инварианты, например, что прикрепленный файл может удалить только автор задачи. Как бы подобная бизнес-логика выглядела в рамках вашей архитектуры?

Меня тянет в сторону MVVM-паттерна, но как-будто бы наличие модели как класса с валидацией внутренних значений выглядит излишним, из-за того, что мы уже проверяем данные через ViewModel.