ИМХО его набросы в целом полезны... точнее всегда любопытна реакция на набросы

ну реакцию на "ддд говно" я бы тут посмотрел) должно было норм пригореть)

просто так нельзя сказть ддд — говно

ну реакцию на "ддд говно" я бы тут посмотрел) должно было норм пригореть)

ну смотря кому и в каком контексте ты это говоришь ;)

нужно ведь начинать с каких-то аргументов

просто зайти и сказать — ничего не выйдет.

Сергей, DDD говно!

OOP лучше!

чтобы не быть голословным

https://www.youtube.com/watch?v=ckjAWXJWZEY

Легчайший наброс: Джависты не люди :)

)))))))))

Цитата про него с нашего форума: "Он сделал сеттер TransactionScript::setId(). И назвал это «sql speaking object». И написал книгу, выступает на конференциях. Своего рода Евгений Попов в мире архитектуры."

ну или сказать, что в джаве нет ооп, там просто скрытая сахором процедурщина

не то что в эрланге

ну тут вроде интерсно говорит https://www.youtube.com/watch?v=lfdAwl3-X_c

ну тут вроде интерсно говорит https://www.youtube.com/watch?v=lfdAwl3-X_c

Скрытая реклама Microsoft?)

Скрытая реклама Microsoft?)

в смысле?

В смысле, в докладе

В смысле, в докладе

я еще не все посмотрел, но чет не заметил. Ты о чем?

книга, которую microsoft издал, полагаю

Посмотрел я этот его доклад, помоему дельные вещи говорит

меня никогда не покидает мысль, что когда люди говорят про правльный ооп, они говорят про фп с объектами

а тут еще он рассказывает про его правильную инкапсуляцию - все операции с объектом должны проходить внутри объекта

это так монады в хаскеле работают, лол

мы не создаем объект State и работаем с ним извне, записывая и читая из него, мы работаем внутри него, а когда выходим из него (запускаем стейт), мы теряем доступ к стейту

на понятном примере для вас - мы так работаем с промисами

мы работаем с промисом исключительно внутри промиса через .then

книга, которую microsoft издал, полагаю

Угу

ну таки нет, то, что я выше написал - немного другая идея, он говорил просто делать имена методов, которые не будут отражать структуру класса, а не проводить всю работу с объектом X внутри X

ну таки нет, то, что я выше написал - немного другая идея, он говорил просто делать имена методов, которые не будут отражать структуру класса, а не проводить всю работу с объектом X внутри X

Не досмотрел, но разве он говорил не о том, что объект будет объектом, если он будет уметь делать все что должен, а не быть тупа хранилищем, ну, и при этом косить под объект?

Не досмотрел, но разве он говорил не о том, что объект будет объектом, если он будет уметь делать все что должен, а не быть тупа хранилищем, ну, и при этом косить под объект?

нет. он говорил о том что в ооп все должно быть объектами. Не надо гетеров, сеторов, статик. Только инмутабле объекты дают тру ооп

Ну, дык, если не будет геттеров и сеттеров, то объект будет делать то, что ему положенно внутри себя, а не отдавать данные с которыми будет потом работать кто-то другой, в таком случае, он не будет косить под объект (его слова)

Ну, то есть, в целом, как я понял: Если объект отдает свои данные просто так, он нарушает инкапсуляцию и является не объектом, а хранилищем, которое косит под объект Чтобы он был объектом, он должен делать манипуляции с данными только у себя внутри

write model :)

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

Сергей, DDD говно!

твое DDD - возможно)

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

проплачено

“Проектирование по контракту: полезности концепции” https://medium.com/@pkolmakov/%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BF%D0%BE-%D0%BA%D0%BE%D0%BD%D1%82%D1%80%D0%B0%D0%BA%D1%82%D1%83-%D0%BF%D0%BE%D0%BB%D0%B5%D0%B7%D0%BD%D0%BE%D1%81%D1%82%D0%B8-%D0%BA%D0%BE%D0%BD%D1%86%D0%B5%D0%BF%D1%86%D0%B8%D0%B8-4da27e66fc31

Провел митап...не знаю, мож кому полезно будет. Сделал как мог. Не пинайте сильно.

В феврале собираюсь на Clean Architecture. Если вдруг кому хочется книжку с автографом дяди Боба - пишите.

В феврале собираюсь на Clean Architecture. Если вдруг кому хочется книжку с автографом дяди Боба - пишите.

Пишу

В феврале собираюсь на Clean Architecture. Если вдруг кому хочется книжку с автографом дяди Боба - пишите.

будешь потом везти пару десятков книг)

Книги я потом могу по почте отправить.

лол)

В феврале собираюсь на Clean Architecture. Если вдруг кому хочется книжку с автографом дяди Боба - пишите.

А ты из какого города?

А ты из какого города?

Сан-Франциско Бэй Эрия (Newark, CA)

конфа в Далласе

Сан-Франциско Бэй Эрия (Newark, CA)

?

С книжками схема следующая. Заказываете на амазоне доставку на мой адрес в Калифорнии (адрес скажу в ЛС). Я подписываю и отправляю вам по USPS. Стоимость посылки можно рассчитать тут https://postcalc.usps.com/?gclid=Cj0KCQiA38jRBRCQARIsACEqIeue60cqeC78ZNJqhdwz_3EcqC4tJmpnct6FAWlqhOVkCLiUq0torTYaAlBnEALw_wcB мой зип-код 94560

Пацаны

А так ли хуева анемичная модель, как принято считать?

https://www.martinfowler.com/bliki/AnemicDomainModel.html

в частности тебя должно заинтересовать следующее

> By pulling all the behavior out into services, however, you essentially end up with Transaction Scripts, and thus lose the advantages that the domain model can bring. As I discussed in P of EAA, Domain Models aren't always the best tool.

Но вот если логика сложная и затрагивает множество сущностей

Гораздо легче дробить ее по сервисам

Да это по сути пооуедурщина на классах

Но с использованием di и интерфейсов не так уж и страшно это

Код норм читается

Гораздо легче дробить ее по сервисам

по процедурам*

Легок в понимании

А cqrs

Это ли не развитие классической модели

Легок в понимании

ты видимо никогда не работал с реально большими системами?

Это ли не развитие классической модели

нет

Где есть функции и процедуры

ты видимо никогда не работал с реально большими системами?

Работад

В том числе сейчас

Где есть функции и процедуры

там нет функций и процедур, у тебя там есть что-то пишет и что-то что читает. То что ты назвал - скорее всего ты имел ввиду CQS. И это тоже не про это, эро про сайд эффекты.

Но с использованием di и интерфейсов не так уж и страшно это

1. количество сервисов будет заоблочным 2. протестировать это дело в изоляции будет практически невозможно 3. сложнее поддерживать консистентность данных 4. я не знаю почему ты считаешь что код будет проще в понимании... это будет так если у тебя сервисы будут сгруппированы в модули адекватно, а отсюда возвращаемся к изначальной проблеме что люди в декомпозицию не умеют.

просто как-то так случилось что концепты типа whole value как-то в ООП не прежились (что иронично)

А вот если пытаться группировать все таки логику и данные как надо...не приведет ли это к супер жирным моделям? Да можно декомпозировать конечно, но с сервисами это гораздо проще...причем я не говорю про треш вроде классов StatusManager или UserHelper

А вот если пытаться группировать все таки логику и данные как надо...не приведет ли это к супер жирным моделям? Да можно декомпозировать конечно, но с сервисами это гораздо проще...причем я не говорю про треш вроде классов StatusManager или UserHelper

в чем ты меряешь жирность классов?

если в строчках кода - то у тебя тогда будет много файлов, больше зависимостей, меньше изоляции данных, меньше контроля....

если же мы измеряем жирность поведением, то просто больше будешь дробить модели

ну то есть пример какой-бы....

вот есть у нас система, там есть покупатели, продавцы, можно по рефералке регаться, заходить через соц сети.... что б еще добавить... чатиться могут....

ты сделаешь один класс User или как минимум 5 в этой ситуации?

Не один

Много

окей, а в ситуации с анемичной моделью и сервисами?

достаточно будет одного класса User с 50-ю полями или ты все же будешь это дело как-то разбивать?

Тоже много. Были бы тонкие ентити - юзер, продавец, покупатель, регистрация, сообщение и т.д и куча сервисов - мессенджер, товарообмена, регистратор и и т.д

Под тонкими ентити подразумеваю тупо маппинг колонок базы на классы

Тоже много. Были бы тонкие ентити - юзер, продавец, покупатель, регистрация, сообщение и т.д и куча сервисов - мессенджер, товарообмена, регистратор и и т.д

и в чем тут будет профит?

Разная функциональность по разным модулям

а так у тебя не будет разных модулей и разделения функциональности по ним?

месенджер это не только сущность участника, товарообмен - это не только сущность продавца

и ты можешь каждую из этих сущностей поместить в модули "товарообмена" или "месенджера"

и сделать их изолированными

месенджер это не только сущность участника, товарообмен - это не только сущность продавца

Товарообмен я имел ввиду сервис

Например метод buy

Товарообмен я имел ввиду сервис

я понимаю, но выйдет сервис с ~30-40 методов

будешь его дробить?)