Комментарии 8
НЛО прилетело и опубликовало эту надпись здесь
Пробовали применять этот архитектурный паттерн на frontend? Например, в связке с React/Vue.js? Интересно, что из этого получится.
0
Несколько вопросов/замечаний
1.
Смысла генировать тут id, вероятно, нет. Так как в большинстве случаев Id будет генирироваться на клиенте и представлять собой либо последовательный гуид(с нэймспейсом), либо генироваться в базе HiLo/Sequence. В обоих случаех в базовом классе это сделать не получится.
2. Не нашел, а где указывается правило идентичности? Т.е. для Entity это равентсво типа+id или одна и таже ссылка
3. Выброс исключения, во вполне ожидаемой ситуации кстати, не лучшая идея. Стоило бы возвращать какой-либо Result с состоянием Success/Error и ErrorMessage
4.
Так же непонятно, почему в случае если не найдет обьект, кидается исключение. Стоило бы вернуть Option/Maybe и уже на уровень выше решать, что делать(создавать новый в случае, если не найдено или отдавать ошибку)
5. Например, Quantity можно рассмотреть как ValueObject
Ну и DDD это не столько про код, сколько про общение и те стратегические паттерны
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 это не столько про код, сколько про общение и те стратегические паттерны
+1
Благодарю за развернутый комментарий. Попробую ответить.
1. Вы правы про большинство случаев и id с клиента будет использован, если он передан. Но могут быть варианты с созданием сущности на бэкенде и тогда, как Вы упомянули далее, id нужен для определения идентичности сущности;
2. Хорошее замечание, думаю автор оригинальной статьи оставил это на самостоятельную работу;
3. На мой взгляд, это больше вопрос личных предпочтений;
4. Резонно;
5. Дельное замечание.
1. Вы правы про большинство случаев и id с клиента будет использован, если он передан. Но могут быть варианты с созданием сущности на бэкенде и тогда, как Вы упомянули далее, id нужен для определения идентичности сущности;
2. Хорошее замечание, думаю автор оригинальной статьи оставил это на самостоятельную работу;
3. На мой взгляд, это больше вопрос личных предпочтений;
4. Резонно;
5. Дельное замечание.
0
У меня практически тоже самое в ui автоматизации. Очень эффективно, особенно для мобайла. За счёт фабрик и инъекций зависимостей слои автоматически собираются в конструктор под нужную платформу. Код тестов при этом меняется только в случае изменения бизнес требований и никак не зависит от платформы. Если интересно — здесь подробности: www.youtube.com/watch?v=Vx1mO5tw3HE
0
Алсо за примерами можно сходить в документацию Nest.js, там это паттерн по умолчанию, что не удивительно, т.к. Nest — этакий ASP .NET на ноде
+1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Чистая архитектура с Typescript: DDD и слоистая архитектура