SS
Вот тут наш архитектор рассказывает, как у нас получилось: https://youtu.be/9xoP9GCUoDU
спасибо!
Size: a a a
2020 September 13
AM
PHP сила!)
IV
а у вас все по DDD? расскажи, как выглядит?
Многие ребята приносят в проект классы Repository, сервисный слой, value objects, entity и даже агрегаты и считают, что теперь у них точно DDD. Особенно мило это выглядит в типичных CRUD проектах.
Мы проделали работу по идентификации поддоменов и их границ через создание context mapping, определили в каких доменах наше конкурентное преимущество, а что покупаем. Определили как команды коммуницируют: shares kernel, partnership, conformist, customer-supplier, open host и тд. Это живой документ.
У некоторых доменов есть свои эксперты с ubiquitous language и доменная модель которую команды используют для дизайна. Но это только в core домене.
Мы проделали работу по идентификации поддоменов и их границ через создание context mapping, определили в каких доменах наше конкурентное преимущество, а что покупаем. Определили как команды коммуницируют: shares kernel, partnership, conformist, customer-supplier, open host и тд. Это живой документ.
У некоторых доменов есть свои эксперты с ubiquitous language и доменная модель которую команды используют для дизайна. Но это только в core домене.
СА
Вот тут наш архитектор рассказывает, как у нас получилось: https://youtu.be/9xoP9GCUoDU
SS
кое что в опенсорсе даже есть - https://github.com/uber/piranha
интересно, надо нашим подкинуть идею
SS
Многие ребята приносят в проект классы Repository, сервисный слой, value objects, entity и даже агрегаты и считают, что теперь у них точно DDD. Особенно мило это выглядит в типичных CRUD проектах.
Мы проделали работу по идентификации поддоменов и их границ через создание context mapping, определили в каких доменах наше конкурентное преимущество, а что покупаем. Определили как команды коммуницируют: shares kernel, partnership, conformist, customer-supplier, open host и тд. Это живой документ.
У некоторых доменов есть свои эксперты с ubiquitous language и доменная модель которую команды используют для дизайна. Но это только в core домене.
Мы проделали работу по идентификации поддоменов и их границ через создание context mapping, определили в каких доменах наше конкурентное преимущество, а что покупаем. Определили как команды коммуницируют: shares kernel, partnership, conformist, customer-supplier, open host и тд. Это живой документ.
У некоторых доменов есть свои эксперты с ubiquitous language и доменная модель которую команды используют для дизайна. Но это только в core домене.
неплохо!
СА
У нас внутри есть тулзы для удаления stale кода, вроде даже есть команда что их развивает
У Badoo тоже есть, кстати на том же митапе рассказывали: https://youtu.be/b8EypWRbkg0 (слайды: https://speakerdeck.com/badoo_tech/miortvyi-kod-naiti-i-obiezvriedit-danil-mukhamietzianov-badoo)
RK
У Badoo тоже есть, кстати на том же митапе рассказывали: https://youtu.be/b8EypWRbkg0 (слайды: https://speakerdeck.com/badoo_tech/miortvyi-kod-naiti-i-obiezvriedit-danil-mukhamietzianov-badoo)
насущная проблема большой codebase
RK
есть еще продолжение - автоматический рефакторинг, вроде у sourcegraph что то появилось недавно ну и наши свое тож пилят
СА
насущная проблема большой codebase
Вот кстати, когда меня спрашивают, какой код у меня пишут самые матёрые и крутые инженеры - я люблю отвечать, что самые матёрые и крутые как раз в основном код удаляют, а не пишут)
RK
ну чем выше позиция тем вообще меньше кода на выходе, но больше решений и высокоуровнего (архитектура, диздоки, стайлгайды)
A
Многие ребята приносят в проект классы Repository, сервисный слой, value objects, entity и даже агрегаты и считают, что теперь у них точно DDD. Особенно мило это выглядит в типичных CRUD проектах.
Мы проделали работу по идентификации поддоменов и их границ через создание context mapping, определили в каких доменах наше конкурентное преимущество, а что покупаем. Определили как команды коммуницируют: shares kernel, partnership, conformist, customer-supplier, open host и тд. Это живой документ.
У некоторых доменов есть свои эксперты с ubiquitous language и доменная модель которую команды используют для дизайна. Но это только в core домене.
Мы проделали работу по идентификации поддоменов и их границ через создание context mapping, определили в каких доменах наше конкурентное преимущество, а что покупаем. Определили как команды коммуницируют: shares kernel, partnership, conformist, customer-supplier, open host и тд. Это живой документ.
У некоторых доменов есть свои эксперты с ubiquitous language и доменная модель которую команды используют для дизайна. Но это только в core домене.
жду когда ктонибудь напишет статью "you have to be this tall to use DDD" (по аналогии с самизнаетечем)
СА
жду когда ктонибудь напишет статью "you have to be this tall to use DDD" (по аналогии с самизнаетечем)
Нет, не знаем!
СА
Happy 1600000000, everybody!
A
еще одной секудной ближе к 2038
СА
Пишу текстик о том, что взрослым мальчикам в принципе можно иногда переписывать историю репозитория, если делать это ответственно и избегать противопоказаний. Из противопоказаний вспомнил всего два. Первое, очевидное - это если веткой пользуются другие люди (т.е. можно удалить чужую работу или заставить кого-то локально ветку удалить и заново выкачать). Второе - это если от ветки отведена другая ветка, понятно что никакого merge обратно не получится.
Есть ещё озабоченность тем, что в репо повиснут в пустоте старые коммиты, но это вроде давно решено
Что я забыл?
Есть ещё озабоченность тем, что в репо повиснут в пустоте старые коммиты, но это вроде давно решено
git gc --prune (Gitlab это делает сам по расписанию).Что я забыл?
D
Пишу текстик о том, что взрослым мальчикам в принципе можно иногда переписывать историю репозитория, если делать это ответственно и избегать противопоказаний. Из противопоказаний вспомнил всего два. Первое, очевидное - это если веткой пользуются другие люди (т.е. можно удалить чужую работу или заставить кого-то локально ветку удалить и заново выкачать). Второе - это если от ветки отведена другая ветка, понятно что никакого merge обратно не получится.
Есть ещё озабоченность тем, что в репо повиснут в пустоте старые коммиты, но это вроде давно решено
Что я забыл?
Есть ещё озабоченность тем, что в репо повиснут в пустоте старые коммиты, но это вроде давно решено
git gc --prune (Gitlab это делает сам по расписанию).Что я забыл?
> Что я забыл?
Не поощрять такое поведение. 🌚
Не поощрять такое поведение. 🌚
СА
> Что я забыл?
Не поощрять такое поведение. 🌚
Не поощрять такое поведение. 🌚
Текст как раз посвящён тому, когда "такое поведение" уместно. Например merge request на два десятка файлов и несколько сотен строк изменений, который ревьюится и проходит через QA в течение недели.
D
Текст как раз посвящён тому, когда "такое поведение" уместно. Например merge request на два десятка файлов и несколько сотен строк изменений, который ревьюится и проходит через QA в течение недели.
Вы про squash and merge?