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