Сообщение Re[23]: Что если не разделять строго dto, entity, bo... от 07.01.2026 16:21
Изменено 07.01.2026 17:48 gandjustas
Re[23]: Что если не разделять строго dto, entity, bo...
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Я не утрирую, с 2002 по 2017 год было всего два визионера про DDD, и одна достойная книга про DDD, не на Java, и Фаулер, который активно это все пиарил в своем блоге.
S>А сколько визионеров надо, что технология взлетела? У ООП много было визионеров, тоже 2-3 человека.
Считаем:
1) Создатели языка Simula, где впервые появилось слово class — Оле-Йохан Даль и Кристен Нюгор, оба профессора
2) Алан Кей, который придумал сам термин ООП и язык Smalltalk, который под воздействием Simula получил понятия "класс" и "объект"
3) Бьёрн Страуструп, который идею классов и объектов натянул на С++, дав начало большей части современных ОО-яызыков
Каждый из них в отдельности имеет больше достижений, написал больше статей и больше создал кода, чем все авторы по DDDвместе взятые.
S>По DDD уже много лет конференции проводят -- https://www.youtube.com/@ddd_eu
Это вообще не показатель. Люди астрологией и гомеопатией занимаются, гораздо больше лет конференции проводят. Программисты тоже подвержены влиянию всяких лженаук.
S>>>Я просто не считаю правильным отмахивать от DDD, как о бесполезной штуке. Оно большое, и люди частями или целиком его вполне успешно применяют.
G>>А чем измеряется успех? В том что программа работает? В том что заказчик платит денег? Может это успех вопреки? Может без DDD денег было бы больше, а программа правильнее?
S>Ну какая-то статистика и выборка же есть, этим не одна компания занимается. Метрики такие, например, что сложный софт развивается.
S>Т.е. заказчик деньги платит не зря.
Повторить аргумент про лженауки?
G>>Без сравнения в равных условиях мы не узнаем.
S>Ну такой себе странный аргумент. Лишних денег ни у кого нету. Разве что у крупняка типа ibm, которые могут себе позволить несколько назависимых отделов
S>для решения одной проблемы.
То есть просто вера, что DDD помогает? Верить не мешает. Но для участия в научном споре одной веры недостаточно.
S>>>Что в этом плохого и кто с этим спорит? В DDD есть паттерн Repository, как раз и отвечает за сохранение главных
S>>>доменных сущностей, наверное и таблицы соотв. должны были быть.
G>>Ты не на тот вопрос отвечаешь. Вопрос такой: является ли набор классов без логики, с которыми работает ORM, "моделью предметной области" в понимании ДДД (по книгам)? Я могу однозначно сказать что нет.
S>Без логики не является, и? ORM это не тот уровень, на котором стоит обсуждать DDD.
Почему? Меня интересует только подход к проектированию и написанию кода. Если DDD не про это, то я не понимаю о чем говорить.
S>Он там спрятан за паnтерном Repository.
И какой интерфейс выставляет этот Repository?
G>>>>А кто сказал что отсутствие "объектов доменной модели" автоматически приводит к плохому решению задачи?
S>>>Никто не сказал, просто это, кхм, странно. Задача софта эмулировать соотв. процессы. Как можно эмулировать что-то без соотв. сущностей?
G>>Еще раз. DDD как набор паттернов, говорит нам:
G>>- Domain Model это набор классов с данными поведением, которые соответствуют существительным в едином языке, выработанным между бизнесом и командой разработки
G>>- Вся бизнес-логика (Core Domain) должна быть описана как взаимодействие этих объектов
S>Там вроде, все строится вокруг взаимодействия AggregateRoot'ов, которые несколько больше чем просто "набор классов с данными поведением".
Если для реализации поведения вам нужны Order, Line и Product, то они попадут в один агрегат.
G>>Я сейчас не буду говорить о том, насколько корректно так проектировать программы, но без этого DDD не будет считаться DDD.
S>Я пока понять не могу, что в этом плохого?
Если программа НЕ будет соответствовать паттернам DDD она будет лучше, чем если будет им соответствовать.
S>Это уход от ответа на конкретный вопрос. Речь не про одинаково. Программа написана хорошо, но не покрывает большую часть use-case'ов или делает это криво. У другой все наоборот.
То есть одна программа не решает проблему пользователя, а другая решает.
Только от наличия "модели предметной области" это не зависит. Может быть модель и не решать проблему, а может не быть и решать.
S>Какой программист больше заработает денег?
Зависит от разницы в цене и насколько пользователь готов пожертвовать решением за эту разницу
S>>>Я вообще не вижу противоречия между хорошим кодом и объектами доменной модели. Это прям какая-то странная дихотомия.
G>>Я тоже не вижу. Качество программы и наличие в ней domain model — вещи ортогональные, то есть независимые друг от друга.
S>Ну т.е. можно использовать excel в качестве бд, написан хорошо, данные хранить может. Или все же возьмем что-то другое для данной задачи?
Ты про мой пример? Там конечно эксель не подойдет, ибо нужны ACID транзакции, которые работают конкурентно. Эта задача решается в РСУБД из коробки, даже писать ничего не надо.
Для других задач может и эксель подойти, но он не обеспечивает sql-совместимого интерфейса и не может использоваться с существующими библиотеками, поэтом маловероятно.
G>>>>Является "оперированием объектами доменной модели"?
S>>>Скорее оперирование представлением в бд.
G>>То есть не соответствует DDD никак, да еще и ужасную вещь делает с точки зрения Clean Architecture — прибивает бизнес-логику к инфраструктуре.
G>>Причем этот код решает задачу "сделать отгрузку товаров со склада X", которую крайне сложно описать в DDD, особенно чтобы была изоляция. Внезапно еще и "отгрузка" никак не фигурирует в моделях БД.
S>Этот код может и ракету в космос запустить, дальше что?
Интересное утверждение. Каким образом он может ракету запустить?
G>>Когда у нас программа работает на компьютере пользователя, в одном процессе (адресном пространстве) и её состояние существует столько, сколько существует процесс, то требования будут одни. Если состояние программы хранится во внешнем хранилище, к которому надо обращаться по ненадежной сети, причем обращаться могут несколько пользователей из разных экземпляров программы, то требования получатся совершенно другие. И подходы к проектированию и реализации программы будут разные.
S>Инвариант класса называется, которое Б. Мейер лет 40 назад ввел в обиход. При чем здесь бд или сеть?
Инвариантность класса не помогает обеспечить целостность состояния во внешнем хранилище.
S>>>Вот цитата Б. Мейера отсюда -- https://bertrandmeyer.com/2012/11/27/why-so-many-features/
S>>>
G>>Очень сложно проверить насколько им удалось придумать архитектуру, которая сохраняет целостность и элегантность длительное время.
S>>>Народ использует, конференции ежегодные проводят, значит кому-то заходит.
G>>Это вообще не показатель. Я пережил столько хайпов в ИТ уже, и после каждого еще долго оставались толпы фанатов "кому заходит".
G>>Тем более есть проблема: кроме Clean Architecture и DDD в медийном поле вообще не существует других подходов. У альтернативы ДДД даже названия собственного нет, она состоит из применения принципов YAGNI, KISS, DRY, top-down подхода к проектированию и разработке, частично SOLID.
G>>Многое кстати было описано в книге Pragmatic Programmer Ханта и Томаса (2000 год), то есть за пар лет до фаулера-эванса и там нет такой категоричной упоротости на ООП. Несмотря на то, что части сведений в книге устарели я, с вашего позволения, буду называть подход — Прагматичным Программированием или Прагматичным Проектированием, сокрушённо ПП
G>>Любую теорию, например теорию о полезности DDD, можно считать научной если существует хотя бы один эксперимент, который может теорию опровергнуть, даже если он еще не проведен. Это называется критерий фальсифицируемости поппера.
G>>А если такого эксперимента не существует, то это уже не теория, а вера.
S>Я не понимаю о чем идет речь и к чему эти странные вопросы и ответы с отсылками на Поппера. Возьмите какой-нибудь проект по DDD и подсчитай в нем ф-ии.
И как это поможет доказать что DDD имеет какие-то преимущества?
S>Если так подходить, то сколько надо строк кода, чтобы ООП давал выхлоп?
вот минимальный пример:
Тут и наследование, и инкапсуляция, и полиморфизм, и OCP, и LSP.
Попытка получить от кода те же свойства без наследования, инкапсуляции и полиморфизма ни к чему хорошему не приведут.
А если взять чуть побольше пример, как в GoF про паттерн Composite, то ООП то там еще лучше получается.
S>Может < писать на Си или ФЯ? Но почему-то для простейших задачи на сотни строк кода все равно используют ООП. Странно, правда?
Мне кажется что осмысленно говорить, что кто-то использует ООП, только когда есть наследование, инкапсуляция и полиморфизм.
Я видел много кода на C#, который с точностью до синтаксиса и названия библиотек\неймспейсово\классов\методов можно переписать на Rust. Использует ли такой код на C# ООП? Я считаю что нет.
S>Здравствуйте, gandjustas, Вы писали:
G>>Я не утрирую, с 2002 по 2017 год было всего два визионера про DDD, и одна достойная книга про DDD, не на Java, и Фаулер, который активно это все пиарил в своем блоге.
S>А сколько визионеров надо, что технология взлетела? У ООП много было визионеров, тоже 2-3 человека.
Считаем:
1) Создатели языка Simula, где впервые появилось слово class — Оле-Йохан Даль и Кристен Нюгор, оба профессора
2) Алан Кей, который придумал сам термин ООП и язык Smalltalk, который под воздействием Simula получил понятия "класс" и "объект"
3) Бьёрн Страуструп, который идею классов и объектов натянул на С++, дав начало большей части современных ОО-яызыков
Каждый из них в отдельности имеет больше достижений, написал больше статей и больше создал кода, чем все авторы по DDDвместе взятые.
S>По DDD уже много лет конференции проводят -- https://www.youtube.com/@ddd_eu
Это вообще не показатель. Люди астрологией и гомеопатией занимаются, гораздо больше лет конференции проводят. Программисты тоже подвержены влиянию всяких лженаук.
S>>>Я просто не считаю правильным отмахивать от DDD, как о бесполезной штуке. Оно большое, и люди частями или целиком его вполне успешно применяют.
G>>А чем измеряется успех? В том что программа работает? В том что заказчик платит денег? Может это успех вопреки? Может без DDD денег было бы больше, а программа правильнее?
S>Ну какая-то статистика и выборка же есть, этим не одна компания занимается. Метрики такие, например, что сложный софт развивается.
S>Т.е. заказчик деньги платит не зря.
Повторить аргумент про лженауки?
G>>Без сравнения в равных условиях мы не узнаем.
S>Ну такой себе странный аргумент. Лишних денег ни у кого нету. Разве что у крупняка типа ibm, которые могут себе позволить несколько назависимых отделов
S>для решения одной проблемы.
То есть просто вера, что DDD помогает? Верить не мешает. Но для участия в научном споре одной веры недостаточно.
S>>>Что в этом плохого и кто с этим спорит? В DDD есть паттерн Repository, как раз и отвечает за сохранение главных
S>>>доменных сущностей, наверное и таблицы соотв. должны были быть.
G>>Ты не на тот вопрос отвечаешь. Вопрос такой: является ли набор классов без логики, с которыми работает ORM, "моделью предметной области" в понимании ДДД (по книгам)? Я могу однозначно сказать что нет.
S>Без логики не является, и? ORM это не тот уровень, на котором стоит обсуждать DDD.
Почему? Меня интересует только подход к проектированию и написанию кода. Если DDD не про это, то я не понимаю о чем говорить.
S>Он там спрятан за паnтерном Repository.
И какой интерфейс выставляет этот Repository?
G>>>>А кто сказал что отсутствие "объектов доменной модели" автоматически приводит к плохому решению задачи?
S>>>Никто не сказал, просто это, кхм, странно. Задача софта эмулировать соотв. процессы. Как можно эмулировать что-то без соотв. сущностей?
G>>Еще раз. DDD как набор паттернов, говорит нам:
G>>- Domain Model это набор классов с данными поведением, которые соответствуют существительным в едином языке, выработанным между бизнесом и командой разработки
G>>- Вся бизнес-логика (Core Domain) должна быть описана как взаимодействие этих объектов
S>Там вроде, все строится вокруг взаимодействия AggregateRoot'ов, которые несколько больше чем просто "набор классов с данными поведением".
Если для реализации поведения вам нужны Order, Line и Product, то они попадут в один агрегат.
G>>Я сейчас не буду говорить о том, насколько корректно так проектировать программы, но без этого DDD не будет считаться DDD.
S>Я пока понять не могу, что в этом плохого?
Если программа НЕ будет соответствовать паттернам DDD она будет лучше, чем если будет им соответствовать.
S>Это уход от ответа на конкретный вопрос. Речь не про одинаково. Программа написана хорошо, но не покрывает большую часть use-case'ов или делает это криво. У другой все наоборот.
То есть одна программа не решает проблему пользователя, а другая решает.
Только от наличия "модели предметной области" это не зависит. Может быть модель и не решать проблему, а может не быть и решать.
S>Какой программист больше заработает денег?
Зависит от разницы в цене и насколько пользователь готов пожертвовать решением за эту разницу
S>>>Я вообще не вижу противоречия между хорошим кодом и объектами доменной модели. Это прям какая-то странная дихотомия.
G>>Я тоже не вижу. Качество программы и наличие в ней domain model — вещи ортогональные, то есть независимые друг от друга.
S>Ну т.е. можно использовать excel в качестве бд, написан хорошо, данные хранить может. Или все же возьмем что-то другое для данной задачи?
Ты про мой пример? Там конечно эксель не подойдет, ибо нужны ACID транзакции, которые работают конкурентно. Эта задача решается в РСУБД из коробки, даже писать ничего не надо.
Для других задач может и эксель подойти, но он не обеспечивает sql-совместимого интерфейса и не может использоваться с существующими библиотеками, поэтом маловероятно.
G>>>>Является "оперированием объектами доменной модели"?
S>>>Скорее оперирование представлением в бд.
G>>То есть не соответствует DDD никак, да еще и ужасную вещь делает с точки зрения Clean Architecture — прибивает бизнес-логику к инфраструктуре.
G>>Причем этот код решает задачу "сделать отгрузку товаров со склада X", которую крайне сложно описать в DDD, особенно чтобы была изоляция. Внезапно еще и "отгрузка" никак не фигурирует в моделях БД.
S>Этот код может и ракету в космос запустить, дальше что?
Интересное утверждение. Каким образом он может ракету запустить?
G>>Когда у нас программа работает на компьютере пользователя, в одном процессе (адресном пространстве) и её состояние существует столько, сколько существует процесс, то требования будут одни. Если состояние программы хранится во внешнем хранилище, к которому надо обращаться по ненадежной сети, причем обращаться могут несколько пользователей из разных экземпляров программы, то требования получатся совершенно другие. И подходы к проектированию и реализации программы будут разные.
S>Инвариант класса называется, которое Б. Мейер лет 40 назад ввел в обиход. При чем здесь бд или сеть?
Инвариантность класса не помогает обеспечить целостность состояния во внешнем хранилище.
S>>>Вот цитата Б. Мейера отсюда -- https://bertrandmeyer.com/2012/11/27/why-so-many-features/
S>>>
S>>>Апологет DDD какай-то такой целью и задавались. На сколько вышло --S>>>It is easy to complain about software bloat, and examples of needlessly complex system abound. But your bloat may be my lifeline, and what I dismiss as superfluous may for you be essential. To paraphrase a comment by Ichbiah, the designer of Ada, small systems solve small problems. Outside of academic prototypes it is inevitable that a successful software system will grow in complexity if it is to address the variety of users’ needs and circumstances. What matters is not size but consistency: maintaining a well-defined architecture that can sustain that growth without imperiling the system’s fundamental solidity and elegance.
G>>Очень сложно проверить насколько им удалось придумать архитектуру, которая сохраняет целостность и элегантность длительное время.
S>>>Народ использует, конференции ежегодные проводят, значит кому-то заходит.
G>>Это вообще не показатель. Я пережил столько хайпов в ИТ уже, и после каждого еще долго оставались толпы фанатов "кому заходит".
G>>Тем более есть проблема: кроме Clean Architecture и DDD в медийном поле вообще не существует других подходов. У альтернативы ДДД даже названия собственного нет, она состоит из применения принципов YAGNI, KISS, DRY, top-down подхода к проектированию и разработке, частично SOLID.
G>>Многое кстати было описано в книге Pragmatic Programmer Ханта и Томаса (2000 год), то есть за пар лет до фаулера-эванса и там нет такой категоричной упоротости на ООП. Несмотря на то, что части сведений в книге устарели я, с вашего позволения, буду называть подход — Прагматичным Программированием или Прагматичным Проектированием, сокрушённо ПП
G>>Любую теорию, например теорию о полезности DDD, можно считать научной если существует хотя бы один эксперимент, который может теорию опровергнуть, даже если он еще не проведен. Это называется критерий фальсифицируемости поппера.
G>>А если такого эксперимента не существует, то это уже не теория, а вера.
S>Я не понимаю о чем идет речь и к чему эти странные вопросы и ответы с отсылками на Поппера. Возьмите какой-нибудь проект по DDD и подсчитай в нем ф-ии.
И как это поможет доказать что DDD имеет какие-то преимущества?
S>Если так подходить, то сколько надо строк кода, чтобы ООП давал выхлоп?
вот минимальный пример:
abstract class CollectionBase<T>
{
public int Count { get; private set; }
protected virtual void AddCore(T item)
public void Add(T item)
{
AddCore(item);
Count+=1;
}
protected virtual T GetCore(int index);
public T Get(int index)
{
ArgumentOutOfRangeException.ThrowIfGreaterThanOrEqual(index, Count);
ArgumentOutOfRangeException.ThrowIfNegative(index);
return GetCore(index);
}
}Тут и наследование, и инкапсуляция, и полиморфизм, и OCP, и LSP.
Попытка получить от кода те же свойства без наследования, инкапсуляции и полиморфизма ни к чему хорошему не приведут.
А если взять чуть побольше пример, как в GoF про паттерн Composite, то ООП то там еще лучше получается.
S>Может < писать на Си или ФЯ? Но почему-то для простейших задачи на сотни строк кода все равно используют ООП. Странно, правда?
Мне кажется что осмысленно говорить, что кто-то использует ООП, только когда есть наследование, инкапсуляция и полиморфизм.
Я видел много кода на C#, который с точностью до синтаксиса и названия библиотек\неймспейсово\классов\методов можно переписать на Rust. Использует ли такой код на C# ООП? Я считаю что нет.
Re[23]: Что если не разделять строго dto, entity, bo...
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Я не утрирую, с 2002 по 2017 год было всего два визионера про DDD, и одна достойная книга про DDD, не на Java, и Фаулер, который активно это все пиарил в своем блоге.
S>А сколько визионеров надо, что технология взлетела? У ООП много было визионеров, тоже 2-3 человека.
Считаем:
1) Создатели языка Simula, где впервые появилось слово class — Оле-Йохан Даль и Кристен Нюгор, оба профессора
2) Алан Кей, который придумал сам термин ООП и язык Smalltalk, который под воздействием Simula получил понятия "класс" и "объект"
3) Бьёрн Страуструп, который идею классов и объектов натянул на С++, дав начало большей части современных ОО-яызыков
Каждый из них в отдельности имеет больше достижений, написал больше статей и больше создал кода, чем все авторы по DDDвместе взятые.
S>По DDD уже много лет конференции проводят -- https://www.youtube.com/@ddd_eu
Это вообще не показатель. Люди астрологией и гомеопатией занимаются, гораздо больше лет конференции проводят. Программисты тоже подвержены влиянию всяких лженаук.
S>>>Я просто не считаю правильным отмахивать от DDD, как о бесполезной штуке. Оно большое, и люди частями или целиком его вполне успешно применяют.
G>>А чем измеряется успех? В том что программа работает? В том что заказчик платит денег? Может это успех вопреки? Может без DDD денег было бы больше, а программа правильнее?
S>Ну какая-то статистика и выборка же есть, этим не одна компания занимается. Метрики такие, например, что сложный софт развивается.
S>Т.е. заказчик деньги платит не зря.
Повторить аргумент про лженауки?
G>>Без сравнения в равных условиях мы не узнаем.
S>Ну такой себе странный аргумент. Лишних денег ни у кого нету. Разве что у крупняка типа ibm, которые могут себе позволить несколько назависимых отделов
S>для решения одной проблемы.
То есть просто вера, что DDD помогает? Верить не мешает. Но для участия в научном споре одной веры недостаточно.
S>>>Что в этом плохого и кто с этим спорит? В DDD есть паттерн Repository, как раз и отвечает за сохранение главных
S>>>доменных сущностей, наверное и таблицы соотв. должны были быть.
G>>Ты не на тот вопрос отвечаешь. Вопрос такой: является ли набор классов без логики, с которыми работает ORM, "моделью предметной области" в понимании ДДД (по книгам)? Я могу однозначно сказать что нет.
S>Без логики не является, и? ORM это не тот уровень, на котором стоит обсуждать DDD.
Почему? Меня интересует только подход к проектированию и написанию кода. Если DDD не про это, то я не понимаю о чем говорить.
S>Он там спрятан за паnтерном Repository.
И какой интерфейс выставляет этот Repository?
G>>>>А кто сказал что отсутствие "объектов доменной модели" автоматически приводит к плохому решению задачи?
S>>>Никто не сказал, просто это, кхм, странно. Задача софта эмулировать соотв. процессы. Как можно эмулировать что-то без соотв. сущностей?
G>>Еще раз. DDD как набор паттернов, говорит нам:
G>>- Domain Model это набор классов с данными поведением, которые соответствуют существительным в едином языке, выработанным между бизнесом и командой разработки
G>>- Вся бизнес-логика (Core Domain) должна быть описана как взаимодействие этих объектов
S>Там вроде, все строится вокруг взаимодействия AggregateRoot'ов, которые несколько больше чем просто "набор классов с данными поведением".
Если для реализации поведения вам нужны Order, Line и Product, то они попадут в один агрегат.
G>>Я сейчас не буду говорить о том, насколько корректно так проектировать программы, но без этого DDD не будет считаться DDD.
S>Я пока понять не могу, что в этом плохого?
Если программа НЕ будет соответствовать паттернам DDD она будет лучше, чем если будет им соответствовать.
S>Это уход от ответа на конкретный вопрос. Речь не про одинаково. Программа написана хорошо, но не покрывает большую часть use-case'ов или делает это криво. У другой все наоборот.
То есть одна программа не решает проблему пользователя, а другая решает.
Только от наличия "модели предметной области" это не зависит. Может быть модель и не решать проблему, а может не быть и решать.
S>Какой программист больше заработает денег?
Зависит от разницы в цене и насколько пользователь готов пожертвовать решением за эту разницу
S>>>Я вообще не вижу противоречия между хорошим кодом и объектами доменной модели. Это прям какая-то странная дихотомия.
G>>Я тоже не вижу. Качество программы и наличие в ней domain model — вещи ортогональные, то есть независимые друг от друга.
S>Ну т.е. можно использовать excel в качестве бд, написан хорошо, данные хранить может. Или все же возьмем что-то другое для данной задачи?
Ты про мой пример? Там конечно эксель не подойдет, ибо нужны ACID транзакции, которые работают конкурентно. Эта задача решается в РСУБД из коробки, даже писать ничего не надо.
Для других задач может и эксель подойти, но он не обеспечивает sql-совместимого интерфейса и не может использоваться с существующими библиотеками, поэтом маловероятно.
G>>>>Является "оперированием объектами доменной модели"?
S>>>Скорее оперирование представлением в бд.
G>>То есть не соответствует DDD никак, да еще и ужасную вещь делает с точки зрения Clean Architecture — прибивает бизнес-логику к инфраструктуре.
G>>Причем этот код решает задачу "сделать отгрузку товаров со склада X", которую крайне сложно описать в DDD, особенно чтобы была изоляция. Внезапно еще и "отгрузка" никак не фигурирует в моделях БД.
S>Этот код может и ракету в космос запустить, дальше что?
Интересное утверждение. Каким образом он может ракету запустить?
G>>Когда у нас программа работает на компьютере пользователя, в одном процессе (адресном пространстве) и её состояние существует столько, сколько существует процесс, то требования будут одни. Если состояние программы хранится во внешнем хранилище, к которому надо обращаться по ненадежной сети, причем обращаться могут несколько пользователей из разных экземпляров программы, то требования получатся совершенно другие. И подходы к проектированию и реализации программы будут разные.
S>Инвариант класса называется, которое Б. Мейер лет 40 назад ввел в обиход. При чем здесь бд или сеть?
Инвариантность класса не помогает обеспечить целостность состояния во внешнем хранилище.
G>>Любую теорию, например теорию о полезности DDD, можно считать научной если существует хотя бы один эксперимент, который может теорию опровергнуть, даже если он еще не проведен. Это называется критерий фальсифицируемости поппера.
G>>А если такого эксперимента не существует, то это уже не теория, а вера.
S>Я не понимаю о чем идет речь и к чему эти странные вопросы и ответы с отсылками на Поппера. Возьмите какой-нибудь проект по DDD и подсчитай в нем ф-ии.
И как это поможет доказать что DDD имеет какие-то преимущества?
S>Если так подходить, то сколько надо строк кода, чтобы ООП давал выхлоп?
вот минимальный пример:
Тут и наследование, и инкапсуляция, и полиморфизм, и OCP, и LSP.
Попытка получить от кода те же свойства без наследования, инкапсуляции и полиморфизма ни к чему хорошему не приведут.
А если взять чуть побольше пример, как в GoF про паттерн Composite, то ООП то там еще лучше получается.
S>Может < писать на Си или ФЯ? Но почему-то для простейших задачи на сотни строк кода все равно используют ООП. Странно, правда?
Мне кажется что осмысленно говорить, что кто-то использует ООП, только когда есть наследование, инкапсуляция и полиморфизм.
Я видел много кода на C#, который с точностью до синтаксиса и названия библиотек\неймспейсово\классов\методов можно переписать на Rust. Использует ли такой код на C# ООП? Я считаю что нет.
S>Здравствуйте, gandjustas, Вы писали:
G>>Я не утрирую, с 2002 по 2017 год было всего два визионера про DDD, и одна достойная книга про DDD, не на Java, и Фаулер, который активно это все пиарил в своем блоге.
S>А сколько визионеров надо, что технология взлетела? У ООП много было визионеров, тоже 2-3 человека.
Считаем:
1) Создатели языка Simula, где впервые появилось слово class — Оле-Йохан Даль и Кристен Нюгор, оба профессора
2) Алан Кей, который придумал сам термин ООП и язык Smalltalk, который под воздействием Simula получил понятия "класс" и "объект"
3) Бьёрн Страуструп, который идею классов и объектов натянул на С++, дав начало большей части современных ОО-яызыков
Каждый из них в отдельности имеет больше достижений, написал больше статей и больше создал кода, чем все авторы по DDDвместе взятые.
S>По DDD уже много лет конференции проводят -- https://www.youtube.com/@ddd_eu
Это вообще не показатель. Люди астрологией и гомеопатией занимаются, гораздо больше лет конференции проводят. Программисты тоже подвержены влиянию всяких лженаук.
S>>>Я просто не считаю правильным отмахивать от DDD, как о бесполезной штуке. Оно большое, и люди частями или целиком его вполне успешно применяют.
G>>А чем измеряется успех? В том что программа работает? В том что заказчик платит денег? Может это успех вопреки? Может без DDD денег было бы больше, а программа правильнее?
S>Ну какая-то статистика и выборка же есть, этим не одна компания занимается. Метрики такие, например, что сложный софт развивается.
S>Т.е. заказчик деньги платит не зря.
Повторить аргумент про лженауки?
G>>Без сравнения в равных условиях мы не узнаем.
S>Ну такой себе странный аргумент. Лишних денег ни у кого нету. Разве что у крупняка типа ibm, которые могут себе позволить несколько назависимых отделов
S>для решения одной проблемы.
То есть просто вера, что DDD помогает? Верить не мешает. Но для участия в научном споре одной веры недостаточно.
S>>>Что в этом плохого и кто с этим спорит? В DDD есть паттерн Repository, как раз и отвечает за сохранение главных
S>>>доменных сущностей, наверное и таблицы соотв. должны были быть.
G>>Ты не на тот вопрос отвечаешь. Вопрос такой: является ли набор классов без логики, с которыми работает ORM, "моделью предметной области" в понимании ДДД (по книгам)? Я могу однозначно сказать что нет.
S>Без логики не является, и? ORM это не тот уровень, на котором стоит обсуждать DDD.
Почему? Меня интересует только подход к проектированию и написанию кода. Если DDD не про это, то я не понимаю о чем говорить.
S>Он там спрятан за паnтерном Repository.
И какой интерфейс выставляет этот Repository?
G>>>>А кто сказал что отсутствие "объектов доменной модели" автоматически приводит к плохому решению задачи?
S>>>Никто не сказал, просто это, кхм, странно. Задача софта эмулировать соотв. процессы. Как можно эмулировать что-то без соотв. сущностей?
G>>Еще раз. DDD как набор паттернов, говорит нам:
G>>- Domain Model это набор классов с данными поведением, которые соответствуют существительным в едином языке, выработанным между бизнесом и командой разработки
G>>- Вся бизнес-логика (Core Domain) должна быть описана как взаимодействие этих объектов
S>Там вроде, все строится вокруг взаимодействия AggregateRoot'ов, которые несколько больше чем просто "набор классов с данными поведением".
Если для реализации поведения вам нужны Order, Line и Product, то они попадут в один агрегат.
G>>Я сейчас не буду говорить о том, насколько корректно так проектировать программы, но без этого DDD не будет считаться DDD.
S>Я пока понять не могу, что в этом плохого?
Если программа НЕ будет соответствовать паттернам DDD она будет лучше, чем если будет им соответствовать.
S>Это уход от ответа на конкретный вопрос. Речь не про одинаково. Программа написана хорошо, но не покрывает большую часть use-case'ов или делает это криво. У другой все наоборот.
То есть одна программа не решает проблему пользователя, а другая решает.
Только от наличия "модели предметной области" это не зависит. Может быть модель и не решать проблему, а может не быть и решать.
S>Какой программист больше заработает денег?
Зависит от разницы в цене и насколько пользователь готов пожертвовать решением за эту разницу
S>>>Я вообще не вижу противоречия между хорошим кодом и объектами доменной модели. Это прям какая-то странная дихотомия.
G>>Я тоже не вижу. Качество программы и наличие в ней domain model — вещи ортогональные, то есть независимые друг от друга.
S>Ну т.е. можно использовать excel в качестве бд, написан хорошо, данные хранить может. Или все же возьмем что-то другое для данной задачи?
Ты про мой пример? Там конечно эксель не подойдет, ибо нужны ACID транзакции, которые работают конкурентно. Эта задача решается в РСУБД из коробки, даже писать ничего не надо.
Для других задач может и эксель подойти, но он не обеспечивает sql-совместимого интерфейса и не может использоваться с существующими библиотеками, поэтом маловероятно.
G>>>>Является "оперированием объектами доменной модели"?
S>>>Скорее оперирование представлением в бд.
G>>То есть не соответствует DDD никак, да еще и ужасную вещь делает с точки зрения Clean Architecture — прибивает бизнес-логику к инфраструктуре.
G>>Причем этот код решает задачу "сделать отгрузку товаров со склада X", которую крайне сложно описать в DDD, особенно чтобы была изоляция. Внезапно еще и "отгрузка" никак не фигурирует в моделях БД.
S>Этот код может и ракету в космос запустить, дальше что?
Интересное утверждение. Каким образом он может ракету запустить?
G>>Когда у нас программа работает на компьютере пользователя, в одном процессе (адресном пространстве) и её состояние существует столько, сколько существует процесс, то требования будут одни. Если состояние программы хранится во внешнем хранилище, к которому надо обращаться по ненадежной сети, причем обращаться могут несколько пользователей из разных экземпляров программы, то требования получатся совершенно другие. И подходы к проектированию и реализации программы будут разные.
S>Инвариант класса называется, которое Б. Мейер лет 40 назад ввел в обиход. При чем здесь бд или сеть?
Инвариантность класса не помогает обеспечить целостность состояния во внешнем хранилище.
G>>Любую теорию, например теорию о полезности DDD, можно считать научной если существует хотя бы один эксперимент, который может теорию опровергнуть, даже если он еще не проведен. Это называется критерий фальсифицируемости поппера.
G>>А если такого эксперимента не существует, то это уже не теория, а вера.
S>Я не понимаю о чем идет речь и к чему эти странные вопросы и ответы с отсылками на Поппера. Возьмите какой-нибудь проект по DDD и подсчитай в нем ф-ии.
И как это поможет доказать что DDD имеет какие-то преимущества?
S>Если так подходить, то сколько надо строк кода, чтобы ООП давал выхлоп?
вот минимальный пример:
abstract class CollectionBase<T>
{
public int Count { get; private set; }
protected virtual void AddCore(T item)
public void Add(T item)
{
AddCore(item);
Count+=1;
}
protected virtual T GetCore(int index);
public T Get(int index)
{
ArgumentOutOfRangeException.ThrowIfGreaterThanOrEqual(index, Count);
ArgumentOutOfRangeException.ThrowIfNegative(index);
return GetCore(index);
}
}Тут и наследование, и инкапсуляция, и полиморфизм, и OCP, и LSP.
Попытка получить от кода те же свойства без наследования, инкапсуляции и полиморфизма ни к чему хорошему не приведут.
А если взять чуть побольше пример, как в GoF про паттерн Composite, то ООП то там еще лучше получается.
S>Может < писать на Си или ФЯ? Но почему-то для простейших задачи на сотни строк кода все равно используют ООП. Странно, правда?
Мне кажется что осмысленно говорить, что кто-то использует ООП, только когда есть наследование, инкапсуляция и полиморфизм.
Я видел много кода на C#, который с точностью до синтаксиса и названия библиотек\неймспейсово\классов\методов можно переписать на Rust. Использует ли такой код на C# ООП? Я считаю что нет.