всех с праздником!

может тут есть кто активно юзает cqrs + es?

пилил скорее crs (без query) + es. проект на 4 месяца в соло. прокладка для небольшого биллинга - там было удобно. по цене не дорого, но не было версионирования команд и боли с bc.

даже можно сказать удобно

если покапитанить, то проекты с большим горизонтом будут дорого стоить из-за суппорта старых команд/квери. имхо не для PHP эта тема, а больше для махрового энтерпрайза

а, сорри, тут про ООП чат :)

И снова ходил в отпуск, и опять вернулся из него, с небольшим сообщением про парадигмы программирования. Если попытаться ответить на вопрос, какую из парадигм или идей (прочитанных, услышанных, изученных) я нахожу максимально полезной - не в теории, а на практике, то я ответил бы неожиданно. Это будет не ООП, не ФП, и не другие П, ДДД и ТДД. Это будет контрактно-ориентированное программирование. Положительный эффект от него заметен настолько явно, что в своей работе мы закрепили это даже в соглашениях о кодировании: - все без исключения публичные функции и методы имеют неотключаемые в релизе проверки входных аргументов и выходных результатов - все остальные функции и методы могут иметь отключаемые или неотключаемые в релизе проверки входных аргументов и возвращаемых значений - любой код может иметь отключаемые в релизе проверки в середине логики. Судя по количеству дефектов в джире, это реально работает, без регистрации и СМС. Часто отпадает даже необходимость в тестах и отладчике.

контрактно-ориентированное программирование - костыль для тех, у кого нет нормальной системы типов?

контракты немножко о большем, нежели просто о типах, так-то

ну это вопрос насколько хорошо ваша система типов позволяет описывать тройки хоара?

я не знаю кто такой этот "архитектор говорит" но формулировка заставляет меня усомниться в том что именно подразумевает автор

как минимум смущает что DbC он называет "парадигмой" и зачем-то туда добавляет всякие там ddd и tdd

например всякие Мэты Прайсы будут говорить что "наиболее эффективна комбинация из ATDD + TDD"

а Кент Бэк будет биться с Мэйерсом за tdd vs dbc просто потому что люди то разные и подходы они под себя делали с их мироощущениями и т.д.

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

вот например еще один спор на тему tdd vs dbc

как по мне когда кто-то говорит "мы пробовали юзать X и это работает" то, если конечно к этому высказыванию не добавлена исчерпывающая информация о контексте (какие проекты, какая команда, что еще пробовали, насколько плотно) то смысла в этом высказывании нет

всем привет!

как оно? есть что нового интересного?

@fes0r , когда в Киев?

давно тебя не было)

я был

я почитываю)

@fes0r , когда в Киев?

ну пока не планировал, @Enleur не зовет же)

так приезжай чо) только пока ивентов не намечается, разве что php friends небольшой митапчик

как оно? есть что нового интересного?

как ты относишься к вопросу CQRS + ES? Особенно в контексте стоимости.

для каких проектов ок, для каких не стоит, может есть какие-то мысли

CQRS хорошо всегда. На стоимость разработки влияет слабо, а плюсов много. ES только если с DDD вкомплекте. Соответственно дорого и далеко не всегда нужно. Все личное имхо.

CQRS хорошо всегда. На стоимость разработки влияет слабо, а плюсов много. ES только если с DDD вкомплекте. Соответственно дорого и далеко не всегда нужно. Все личное имхо.

почему дорого?

и понятно что для бложика в этом нет смысла

Дорого это про DDD

и понятно что большинство приложений по сложности не далеко от бложиков ушли

Дорого это про DDD

но почему ты считаешь что ddd это дорого?)

может быть DDD нужно тогда когда "дорого"?)

то есть вопрос масштабов

Вот да, скорее даже так

Проработать домен задача не тривиальная. Очень часто бизнес сам не понимает свои процессы, соответственно их разбор и нормализация требуют времени и денег.

ну это понятно, и есть всякие ивент сторминги и прочие штуки

с другой стороны - ES дает тебе такую предсказуемость разработки которую не дает никакой другой подход

ну то есть тебе надо что-то добавить - делаешь проекцию данных и вуаля

проще исследовать домен

и на определенных масштабах это становится финансово выгодно

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

Серег, ты знаешь, я сам за CQRS + ES обеими руками, но для этого нужен соответствующий проект коих к сожалению не много

кароч... с cqrs оно как получается... так же как и с ддд

так же как и с блокчейном)

неа

типа можно пользовать

но можно и не пользовать

CQRS ок и реально круто

канеш круто!

CQRS ок и реально круто

а какой смысл в CQRS без ES?

как и ддд

А вот ES (ну и DDD) далеко не всегда

да понятно, что с ES

так же как и с блокчейном)

ну че смарт контракты это весело

в разрыве не круто)

да все весело

хорошие штуки

но вот нужны ли они?

хз хз

я все больше сталкиваюсь с другими вопросами

А вот ES (ну и DDD) далеко не всегда

а как без ES делать CQRS? как у тебя тогда read model выглядит? или ты о том варианте где у тебя write model генерит ивенты но мы тупо храним стэйт и есть read model которую можно склепать из ивентов?

я все больше сталкиваюсь с другими вопросами

расскажи)

Ага

типа что выгоднее: костыль прямо сейчас, или идеальное решение потом никогда? :)

Была мысля (помойму от Udi Dahan) что CQRS нужен тогда когда большая часть агрегатов - Saga.

типа что выгоднее: костыль прямо сейчас, или идеальное решение потом никогда? :)

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

я даже дальше пошел

лучше говно сделать сейчас чем потом

я теперь думаю, что и костыль не нужен)

Код шредингера!

я теперь думаю, что и костыль не нужен)

потому что фича не нужна?

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

которые не столь круты

:)

живой пример: делаем сесурити у проекта, чтоб ни одна вош не пролезла

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

предлагаешь делать более гибкие решения и делать меньше слабых предположений?)

полгода делаем

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

как же так ты не подумал про бэкдоры?

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

приходится лепить костыль

перехватывать сесурити

ну я слабо понимаю о чем ты...

ты не знаешь что такое сесурити? ?

security по нашему

я знаю что такое сесурити, я плохо понимаю в контексте апворка как оно там внутри

и что вы делали

и зачем вам дырочка

я не имею ввиду апворк

в апворке все гораздо сложнее

ну ок, а зачем дырочка то?

даже влазить в подробности не хочу

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

и он не умеет в ориджины и другие хедеры

(потому шо легаси у него на колдфюжине написано, например)

сделать адаптер?)