Чистая архитектура с Typescript: DDD и слоистая архитектура

[@p0vidl0]

За автора оригинальной статьи не скажу. Сам не использовал и есть сомнения, что он может принести больше пользы, чем граблей.

[@superD]

Пробовали применять этот архитектурный паттерн на frontend? Например, в связке с React/Vue.js? Интересно, что из этого получится.

[@p0vidl0]

На реакте не встречал, знаю что в ангуляре и андроиде некоторые активно используют эти идеи.

[@Soupbreak]

Несколько вопросов/замечаний
1.

  constructor(props: T, id?: string) {
    this._id = id ? id : UniqueEntityID()
    ...
  }

Смысла генировать тут id, вероятно, нет. Так как в большинстве случаев Id будет генирироваться на клиенте и представлять собой либо последовательный гуид(с нэймспейсом), либо генироваться в базе HiLo/Sequence. В обоих случаех в базовом классе это сделать не получится.
2. Не нашел, а где указывается правило идентичности? Т.е. для Entity это равентсво типа+id или одна и таже ссылка
3. Выброс исключения, во вполне ожидаемой ситуации кстати, не лучшая идея. Стоило бы возвращать какой-либо Result с состоянием Success/Error и ErrorMessage
4.

  private async _getCart(id: string): Promise<Cart> {
    try {
      const cart = await this.repository.getById(id)
      return cart
    } catch (e) {
      const emptyCart = Cart.create({ id, products: [] })
      return this.repository.create(emptyCart)
    }
  }

Так же непонятно, почему в случае если не найдет обьект, кидается исключение. Стоило бы вернуть Option/Maybe и уже на уровень выше решать, что делать(создавать новый в случае, если не найдено или отдавать ошибку)
5. Например, Quantity можно рассмотреть как ValueObject

Ну и DDD это не столько про код, сколько про общение и те стратегические паттерны

[@p0vidl0]

Благодарю за развернутый комментарий. Попробую ответить.
1. Вы правы про большинство случаев и id с клиента будет использован, если он передан. Но могут быть варианты с созданием сущности на бэкенде и тогда, как Вы упомянули далее, id нужен для определения идентичности сущности;
2. Хорошее замечание, думаю автор оригинальной статьи оставил это на самостоятельную работу;
3. На мой взгляд, это больше вопрос личных предпочтений;
4. Резонно;
5. Дельное замечание.

[@Gennadii_M]

У меня практически тоже самое в ui автоматизации. Очень эффективно, особенно для мобайла. За счёт фабрик и инъекций зависимостей слои автоматически собираются в конструктор под нужную платформу. Код тестов при этом меняется только в случае изменения бизнес требований и никак не зависит от платформы. Если интересно — здесь подробности: www.youtube.com/watch?v=Vx1mO5tw3HE

[@av_in]

Алсо за примерами можно сходить в документацию Nest.js, там это паттерн по умолчанию, что не удивительно, т.к. Nest — этакий ASP .NET на ноде