Писал я датамапперы, но кастил их на структурные теги. Это помогало отвязаться от конкретной реализации и отказаться от внедрения управления данными из сущности, которой манипулирует разработчик. Но чем больше закапывался в теги и рефлексию, тем больше текли абстракции, ведь структура хоть и не могла менять данные в базе, но много знала о них. Думаю для ДДД действительно важнее более явные структуры, в которых есть нужные данные, хоть и придется каждый раз реализовывать датамаппер для каждой сущности. Иначе абстракции протекать начнут.
Вцелом ничего нового. Вероятно, что ДДД было скорее для энтерпрайза создано. Опять же, видно, что для определенных доменов лучше подходит домен-специфичный язык(так, 1с лучше всего для учетных задач, а вот на Го - костыльно как-то получается). Концепт понятный, но в докладе скорее про Чистую архитектуру, а не про ДДД. Про то, что ненужно использовать указатели - прям чето очень спорно. Понятно, что для value objects их лучше не юзать, но для других типов это мастхев.
возможно доклад хороший, но только если в качестве доказательства того, что подход залупа =) первые вопросы сразу же указывают на главные минусы подхода, которые очень значимы.
Какойто бред- не используем Data теги, scan, весь sqlx для базы данных и страдаем от того что мы не можем автоматически заметить свою структуру к таблице. Вот бы бвл автомеппер! Так он есть, и страдание это потому, что мы не используем data теги. вопрос Какого хрена вообще?
Действительно Достойный Доклад
Спасибо за такой шикарный нужный доклад! Выделил главное и донёс слушателю. Максимальное количество пользы в единицу времени👍
Спасибо, отличный обзор DDD на Go
Писал я датамапперы, но кастил их на структурные теги. Это помогало отвязаться от конкретной реализации и отказаться от внедрения управления данными из сущности, которой манипулирует разработчик. Но чем больше закапывался в теги и рефлексию, тем больше текли абстракции, ведь структура хоть и не могла менять данные в базе, но много знала о них. Думаю для ДДД действительно важнее более явные структуры, в которых есть нужные данные, хоть и придется каждый раз реализовывать датамаппер для каждой сущности. Иначе абстракции протекать начнут.
Лучше обложиться dto'шками, чем потом мучаться с протеканиями 1 сущности в другую, тем более что copilot/etc берут много рутины на себя
крутой доклад, полезный. очень понравился.
Вцелом ничего нового. Вероятно, что ДДД было скорее для энтерпрайза создано. Опять же, видно, что для определенных доменов лучше подходит домен-специфичный язык(так, 1с лучше всего для учетных задач, а вот на Го - костыльно как-то получается). Концепт понятный, но в докладе скорее про Чистую архитектуру, а не про ДДД. Про то, что ненужно использовать указатели - прям чето очень спорно. Понятно, что для value objects их лучше не юзать, но для других типов это мастхев.
возможно доклад хороший, но только если в качестве доказательства того, что подход залупа =) первые вопросы сразу же указывают на главные минусы подхода, которые очень значимы.
Какойто бред- не используем Data теги, scan, весь sqlx для базы данных и страдаем от того что мы не можем автоматически заметить свою структуру к таблице. Вот бы бвл автомеппер! Так он есть, и страдание это потому, что мы не используем data теги. вопрос Какого хрена вообще?
Мы помещаем - ааааааа - логику в одно - ааааааа - место - аааааааа и делаем ее - аааааааа - независимой - аааааааа
ААААААА!!!!!!!!
Хотел бы тоже применить фильтр АААААААААААА.
meh