и все эти шины имеют место быть в асинхронной обработке данных в контексте распределенных систем. Ты много таких систем писал?)

Ни одной системы. Только я не совсем понимаю вот это: все эти шины имеют место быть в асинхронной обработке данных в контексте распределенных систем Все эти шины - это реализация CQRS. Сторонники CQRS утверждают, что команды не должны ничего возвращать. И потом приводят всем известные аргументы. Ну и я соглашаюсь с ними, потому что с практической точки зрения не сталкивался с проблемами из-за того, что команды ничего не возращают (если что - пилюкаю веб-приложения на ПХП). Приведи простенький пример, если не сложно. Может, я просто не соображаю.

> Все эти шины - это реализация CQRS. Поправка, это один из вариантов реализации CQRS. > Сторонники CQRS утверждают, что команды не должны ничего возвращать. Это скорее про CQS, где все операции записи (методы) по хорошему должны быть void, но есть скажем pop у стэка. Он одновременно пишет и возвращает. Если тебе надо атомарно что-то такое сделать у тебя будут проблемы. В CQRS команды не должны отвечать за "запросы". То есть это нормально когда команда возвращает скажем идентификатор созданной сущности, но не нормально когда команда возвращает результат какой-то выборки из базы. codebetter.com/gregyoung/2010/02/16/cqrs-task-based-uis-event-sourcing-agh/ - вот например мнение Грэга Янга на этот счет (а он типа главный апологет CQRS/ES). > Приведи простенький пример, если не сложно. любой кейс когда идентификатор извне команды нельзя получить, потому что формирование этого идентификатора требует какиз-то бизнес штук до которых ты не можешь добраться из-за шины.

конкретных кейсов не вспомню но они были

Спасибо за подробный ответ. Буду учиться (впрочем, как всегда).

а мне идея наркоманских шин и басов больше понравилась :(

а мне идея наркоманских шин и басов больше понравилась :(

потому что можно не думать?)

ну думать там как раз чуть больше надо)

ну думать там как раз чуть больше надо)

о чем?)

мы сейчас про использование шины а не о ее имплементации

ладно, уговорил) пойду дальше кофе пить)

ладно, уговорил) пойду дальше кофе пить)

пойду тоже

ну на счет правильного и не правильного я бы это за бортом беседы оставил

Согласен, неправ

Кстати, а как Magento обходится без Smarty шаблонов?

Кстати, а как Magento обходится без Smarty шаблонов?

Вопросы по пыхе в чатик по пыхе плиз

https://t.me/prophp7

Чтобы DDD работал, нужно быть дохера умным человеком по типу самого Эрванса ибо даже он пробирался сквозь тернии достаточно долго. Экранировать реальную модель в бизнес логику это искусство.

Чтобы DDD работал, нужно быть дохера умным человеком по типу самого Эрванса ибо даже он пробирался сквозь тернии достаточно долго. Экранировать реальную модель в бизнес логику это искусство.

Если это действительно так, то DDD никому не нужен. Никто не хочет искусства - всем нужна технология.

Если это действительно так, то DDD никому не нужен. Никто не хочет искусства - всем нужна технология.

а как же мейнтейнабилити?)

Я и говорю - всем нужна технология (==надёжная повторяемость успешного результата), а искусство - это в общем "муза пришла - муза ушла".

Я и говорю - всем нужна технология (==надёжная повторяемость успешного результата), а искусство - это в общем "муза пришла - муза ушла".

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

А может я и не прав - достаточно просто быть дохера умным чуваком чтобы делать гибкое ПО в масштабах корпоративного приложения.

Хотя вообще то Эрванс не в одиночку мутил, а с коллегами.

Чтобы DDD работал, нужно быть дохера умным человеком по типу самого Эрванса ибо даже он пробирался сквозь тернии достаточно долго. Экранировать реальную модель в бизнес логику это искусство.

это не искусство, это простое разделение ответственности и переработка знаний

ну то есть... "искусство" слишком размытое определение. Почти как "умный"

идея DDD в том, что бы уменьшить эффект "стоимости перевода" требований в код. Если у тебя код выражает предметную область достаточно четко, ты лучше понимаешь что делаешь и у тебя больше возможностей по коммуникации с бизнесом. Ты сможешь не просто сказать "но так не работает" а объяснить на языке понятному бизнесу почему. Очень хорошо показывает себя когда у тебя несколько стэкхолдеров которые не могут между собой договориться например)

Скорей бы IRL посмотреть на DDD код нормальных людей :D

Скорей бы IRL посмотреть на DDD код нормальных людей :D

Тебя ждет разочарование)

это не искусство, это простое разделение ответственности и переработка знаний

Ты видел корпоративное приложение с заимплементенным DDD несколько лет?

Ты видел корпоративное приложение с заимплементенным DDD несколько лет?

что для тебя "заимплеменченное DDD"

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

Да, это к тому что это не простое разделение ответственности только, а постоянный контроль любого изменения, который по-любому критичен в перспективе для бизнеса. Потому мне видится создание подобной системы, как картина под кистью великого художника.

Да, это к тому что это не простое разделение ответственности только, а постоянный контроль любого изменения, который по-любому критичен в перспективе для бизнеса. Потому мне видится создание подобной системы, как картина под кистью великого художника.

ты инженер или кто?

Покрайней мере таким я вижу DDD после прочтения книги

Покрайней мере таким я вижу DDD после прочтения книги

ну почитай не эванса а Вернона какого

C

C

Даша не шали

DDD это про единый язык, очень простая идея, что тебе надо штуки в коде и отношения объектов выстраивать в терминах бизнес логики а не пихать "SomethingManager"-ы повсюду

для этого тебе надо разбираться в бизнес логике

+ постоянный рефакторинг

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

ну и реалии, скажем если ты напрямую со стэкхолдерами и экспертами в предметной области не взаимодействуешь - то сам понимаешь что делать DDD в таких условиях затруднительно

О чём мы? Я о том что это сложно, и если тебе просто то ты крутой чувак.

О чём мы? Я о том что это сложно, и если тебе просто то ты крутой чувак.

что бы вышло DDD нужно соблюсти условия определенные. Это не значит что ты мега умный если у тебя DDD выходит.

ну и опять же, DDD это просто "трэйд марк"

это как SOLID

"ты видел людей которые соблюдают принципы SOLID?"

наверное для них надо быть таким же умным как Дядя Боб

что бы вышло DDD нужно соблюсти условия определенные. Это не значит что ты мега умный если у тебя DDD выходит.

Эт твоё мнения, я сравниваю с собой потому считаю таких чуваков мегаумными

GRASP Лармана? Не, мы слишком тупые для этого. Рефакторинг Фаулера - надо быть фаулером что бы рефакторить на своих проектах

Эт твоё мнения, я сравниваю с собой потому считаю таких чуваков мегаумными

а ценность от подобного мнения какая? И выводы. Типа "мне не суждено"?)

ты же понимаешь что это не так)

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

я когда первый раз Эванса читал по факту ничего не понял... ну тоесть года через два совсем по другому воспринималось

GRASP Лармана? Не, мы слишком тупые для этого. Рефакторинг Фаулера - надо быть фаулером что бы рефакторить на своих проектах

Фаулер популяризатор, рефакторинги он все ж списал)

Ну он об этом сам явно пишет

Фаулер братан

Понятно, чьо все на плечах гигантов смотрят далеко

Фаулер популяризатор, рефакторинги он все ж списал)

А Эванс типа не пишет что все это было и до него а он просто в книжке собрал

А Эванс типа не пишет что все это было и до него а он просто в книжке собрал

Эванс собрал разного и дал этому имя

А фаулер просто переписал в книжку

Эванс собрал разного и дал этому имя

Коктейль это не что-то новое, надо просто смешать в определенной пропорции старого)

а ценность от подобного мнения какая? И выводы. Типа "мне не суждено"?)

Мой вывод как раз такой что ты описал ниже - нужно быть подготовленным к этому.

я слабо себе представляю разработчика который умеет в DDD но понятия не имеет что такое information hiding

По мне так проблема всей этой темы с DDD это то, что нет нормальных примеров приближенных к реальности, и выглядит это все как некое шаманство.

оно так одинаково во всём. за что не возьмись

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

И если развивать мысль далее, я думаю что все только зарождается, формируется, устаканивается в разработке. Мы сейчас в каменном веке.

поэтому последние 50 лет промышленной разработки каждая команда или даже каждый девелопер проходит снова и снова

кто-то остается в 60ых

Индустрия еще не сменила поколения. Сейчас немного дико слышать фразы типа "Программист пенсионер"

ну хз

ракетостроение сменило, а программисты не?

60 лет прошло

они электронщики

у меня дядьки компы собирал.. он не программист

Мне кажется, или в СНГ вплоть до конца 90-х разработки ПО как таковой не было , а было программирование на уровне "рассчитать формулы по запуску ракет для Самаровского НИИ им. Ленина"?

И, соответственно, такие вопросы вообще не ставились?

Мне кажется, или в СНГ вплоть до конца 90-х разработки ПО как таковой не было , а было программирование на уровне "рассчитать формулы по запуску ракет для Самаровского НИИ им. Ленина"?

я знаю пару человек которые у нас в Минске начали в 80-ых софт писать

Про подход к проектированию и т.д.

промышленный программинг был

Про подход к проектированию и т.д.

если бы так то проблема была бы только в СНГ

а она глобальна

мы не слабо отстаем

Тогда как в то время на западе, как минимум, точно была промышленная разработка для бизнеса. Банкинг уж точно, до сих пор емнип некоторые банки на ПО 40-летней давности висят

мы не слабо отстаем

а с кем ты сравниваешь?)

с США

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

с США

У тебя есть репрезентативная выборка?)