Домены обособляются не потому что «так надо», а потому что каждый домен — это большой пласт нюансов, который по хорошему должен разрабатываться отдельной командой, но при этом чтобы был понятен другим и его можно было легко протестировать и использовать.
всё так. но обособленность ≠ полная изолированность. буквально в вашем же примере вы запрещаете домену лезть в соседний домен, но разрешаете это делать бизнес-процессу. отсюда получаем дополнительный уровень бизнес-процессов. бизнес-процессы, в вашем понимании, тоже должны быть изолированы друг от друга? или один большой бизнес-процесс может переиспользовать другой более мелкий?
А что мешает задублировать внутрянку бизнес процесса? Это даже не будет нарушением DRY
зависит от ситуации. вы сами пишете, что ddd — это «про перенос бизнес логики, как она есть, в код». если в реальном мире логика сложного бизнес-процесса в том, чтобы полностью переиспользовать несколько мелких бизнес-процессов, то дублирование реализации в коде — это костыль, не отвечающий реальному бизнес-процессу и нужный только для преодоления искусственного ограничения в архитектуре. если же в реальном мире кусок логики сложного бизнес-процесса просто повторяет имеющийся мелкий бизнес-процесс, но не переиспользует его (например, за этот кусок и за мелкий бизнес-процесс отвечают разные подразделения), то дублирование в коде отвечает реальному бизнес-процессу.
Я например не могу придумать сценарий, где «придется» городить супер бизнес процесс.
ничего страшного, это вопрос только времени и опыта. в простой пример с партнёрским кодом вы уже воткнулись, и это привело вас к идее выделения второго уровня (бизнес-процессы). воткнётесь и в более многоуровневую вложенность. проблема лишь в масштабировании: ваш вариант из статьи сейчас фиксирует ровно два уровня (бизнес-процессы и доменные методы) в том числе и для тех ситуаций, когда это избыточно, и для тех, когда этого мало. а композиция позволила бы намазывать ровно то количество слоёв, которое требуют реальные бизнес-процессы (где-то это будет всего один слой и достаточно одного домена, где-то — два, как у вас в статье, а где-то — больше).
Но как только какая то часть внутри усложнится метод createPartner превратится в 100-строчный код с кучей if-ов, уже видел неоднократно.
вот именно появление if-ов и будет очень наглядным сигналом к тому, что бизнес-процессы стали различаться и пора рефакторить: у вас теперь createPartner() не использует стандартный addClientToPartners(), а добавляет в список партнёров как-то иначе. и это нормальная реакция кода на изменение бизнес-процесса в реальности.
Это кстати огромная беда, что разработчики думают только про момент запуска приложения и совсем не думают о последующих этапах жизненного цикла.
лично я бы тут винил представителей немного других профессий, а не разработчиков. но боль ваша понятна, да.
Вы предлагаете метод от сложного к простому
хм, разве? не улавливаю этого в своём предложении. я, наоборот, за упрощение. и предлагаю вместо трёх видов сущностей оставить, грубо говоря, один. концептуально тут тоже просматривается аналогия с ФП и ООП. там где вы предлагаете методы, классы и модули (каждый со своими ограничениями), я предлагаю всё тупо считать функциями и позволить разработчику конкретного приложения собирать из этих функций такого франкенштейна, которого нужно для его конкретного приложения.
Смущает выделение бизнес-процессов в самостоятельные сущности. Тут не вы первый, и, кажется, это частый трюк при попытке натянуть DDD на реальную жизнь: люди стараются сохранить независимость доменов, упираются в невозможность это сделать, потому что в реальности домены не полностью изолированы друг от друга, и пытаются выкрутится тем, что придумывают ещё один слой над доменами, которому разрешают оркестрировать доменами. Окей, что будет, когда вы обнаружите, что бизнес-процессы тоже не полностью изолированы и вам понадобиться какой-то крупный бизнес-процесс, объединяющий несколько уже существующих? Введёте слой супер-бизнес-процессов над слоем бизнес-процессов, который будет оркестрировать бизнес-процессами?
Встречная идея такая: как насчёт отказаться от иллюзорной независимости доменов и разрешить себе композицию доменов и/или доменных методов? Надо же чему-то хорошему у функциональщиков учиться.
• У вас в реальности есть юз-кейс создания клиента — реализуем его в коде доменным методом createClient().
• У вас в реальности есть юз-кейс добавления существующего клиента в партнёры — доменный метод addClientToPartners().
• И у вас есть юз-кейс создания клиента-партнёра, который является композицией предыдущих двух, — оформляем его в виде доменного метода createPartner(), который использует createClient() и addClientToPartners().
Да, получается, доменный метод createPartner() в этом случае зависит от двух других доменных методов. Ну и ничего страшного, потому что и реальный юз-кейс зависит от двух других. Наличие таких зависимостей не делает доменный метод новой сущностью (бизнес-процессом). Это всё ещё просто доменный метод, к которому мы можем прибивать порты. И, да, порты могут быть прибиты в этом примере к любому из трёх доменных методов (хоть к атомарным, хоть к композитноум), потому что все три юз-кейса существуют в реальности и могут работать по отдельности. И, да, нужда в группировке доменных методов в домены вроде как отваливается, потому что каждый публичный доменный метод, реализующий свой юз-кейс (хоть атомарный, хоть композитный) — это и есть как бы самостоятельный маленький домен.
Другими словами, идея в том чтобы в общем случае отказаться от разделения на доменные методы, домены и бизнес-процессы (потому что эти три этажа иногда будут избыточными, а иногда их будет недостаточно) в пользу композиции доменных методов произвольной вложенности, и вложенность будет зависеть от реальной сложности разрабатываемой системы: если у вас в реальности нету сложных составных юз-кейсов, их не появится и в коде, вся система будет состоять из несложных атомарных доменных методов; если же у вас много длинных составных процессов, состоящих их других процессов, состоящих из других процессов и так далее, то вы можете это всё накомпозировать, не придумывая новые сущности и новые соглашения для каждого нового уровня вложенности.
То есть, внизу адаптеры, а над ними — граф юз-кейсов, к которым сверху прибиты порты.
другими словами, автор говорит нам: «договариваться с людьми — больно». а ему в комментах отвечают, мол, действительно больно, но это лучше, чем не договариваться вовсе.
да, понимаю, о чём вы. я думаю, это издержки любой командной работы (и тоже важное отличие от пет-проджектов) — кое-где приходится идти на компромиссы, что само по себе не всегда приятно. вряд ли существует стайл-гайд (или любые другие соглашения), который на 100% совпадал бы со встроенными хотелками всех членов команды. но тут, если вы понимаете, ради чего вы идёте на эти уступки, то вам ок. а если не понимаете — то пишете пост на хабр типа того, который мы с вами комментируем.
Ну, и чем меньше творчества тратится на выдумывание количества пробелов вокруг strict_types или на размышления, можно ли пять строчек оставить в контроллере или это уже многовато, тем больше этого творчества остаётся на реальное решение реальной задачи.
В пет-проджекте вы чаще пишите код, чем читаете. В практически любом командном проекте — наоборот.
Чиня себе дофаминовый цикл с помощью креативненьких реализаций стандартных вещей, вы ломаете дофаминовый цикл любому, кто будет читать этот код после вас (включая вас самого через полгодика).
Артём, обрати внимание, насколько людям непривычно смотреть на эту идею из мира скрама и спринтов. Вероятно, в будущем стоит больше акцентировать внимание на том, что вся эта штука не то что не монтируется со спринтами, а чуть ли не прямо противоречит им.
Тут очень сильно зависит от того, какой запрос (и майндсет) у продакта. Если он приходит с вопросами «через сколько времени такая-то задача будет на проде», то твоя идея (и канбан) работает хорошо. Если он приходит с вопросами «какие фичи будут через неделю на проде», то хорошо работает скрам. Если продакт мыслит потоком отдельных плюс-минус изолированных задач — канбан. Если еженедельными инкрементами — скрам.
это потому что производством в данном случае считается только разработка. «А ведь есть еще тестирование и код-ревью». но они в данной системе оценки воспринимаются не как часть производства, а как издержки на транспортировку или хранение.
Правильно подумали, всё так и было: в рамках компании Skyeng вернулся из тимлидов в разработчики. И да, уменьшение зарплаты было вполне ожидаемо, но в итоге не случилось.
Ну, смотря что для вас downshift. Это вопрос про деньги? Нет, в деньгах я не потерял (даже наоборот).
Во-первых, я хорошо обучен программировать, а управлению людьми я никогда нигде не учился. И мой внутренний перфекционист против того, чтобы делать что-то, за что берёшься, плохо. Но тут работодатель пошёл на встречу и отправил на обучение, дал возможность подтянуть менеджерские навыки, а заодно поглубже заглянуть в профессию и увидеть, что ждёт впереди. И то, что я увидел, мне не понравилось. Я в какой-то момент отчётливо понял про себя, что я всё-таки ремесленник, а не управленец — мне интереснее делать вещи, а не управлять людьми, которые делают вещи. И уж тем более не управлять людьми, которые управляют людьми, которые делают вещи.
Во-вторых, мои интересы в жизни не ограничены пределами работы и профессии. И поэтому для меня во многом решающим стало опыт друзей и знакомых, продвинувшихся или продвигающихся по карьере управленцев. Когда один из них в разговоре со мной с гордостью заявил, что, мол, ура, за прошедший год он достиг очень важного для себя результата: научился работать всего 11 часов в день, — я понял, что ну её нафиг такую работу и такую карьеру, это не мой путь. Буквально на прошлой неделе у меня состоялся похожий диалог с одним знакомым, занимающим в своей компании должность типа CTO, который рассказал, что работает 75 часов в неделю. Я тупо не хочу посвящать работе столько времени, мне есть на что ещё потратить свою жизнь.
Привет. Вас не затруднит сформулировать какие-то вопросы? Что именно интересно? А то тема-то большая, можно много всякого обсуждать. И без конкретики тяжело угадать, про что вам интересно.
Главный лайфхак про поиски квартиры на средний срок (два-три месяца) такой: внезапно хорошо работают соцсети. Мы, конечно, дежурно пробегаем AirBnB, но он давненько никаких приличных по соотношению цена/качество вариантов не приносил. Поэтому последние годы рецепт такой: найти в фейсбуке группы про аренду и/или экспатские группы. Минус в том, что это получается дольше, чем два клика на AirBnB, требует больше усилий и времени. Плюс в том, что это в среднем дешевле.
В некоторых местах, до куда прогресс в виде AirBnB ещё не дошёл, имеет смысл снять на букинге номер на первую неделю, и искать постоянное жильё уже на месте. Это касается Азии, прежде всего. Но даже в Азии иногда срабатывает вариант с фейсбуком (например, прямо сейчас мы живём на Самуи в доме, о котором договорились через фейсбук).
Район выбираем примерно так. Если город новый и хочется его посмотреть — поближе к цивилизации и к тому, что хочется посмотреть. Если не новый и уже обзавелись друзьями — поближе к друзьям.
Перечитал написанное, и как будто слишком общо ответил. Если у вас какие-то более конкретные вопросы, например, про конкретные города — задавайте.
Мне не приходилось, и вопрос с настолько большой разницей часовых поясов мне тоже интересен, т.к. есть мечта пожить в Южной Америке, но непонятно, как организовать свой график дня, работая с коллегами из Евразии.
В Индонезии зимовал коллега из предыдущей команды, без проблем совмещал жизнь на Бали с удалённой работой. Сам я до Индонезии ещё не добрался.
В Малайзии был, но мельком — на несколько дней летал в Куала-Лумпур на визаран из Таиланда. Столица оставила очень неприятные впечатления (но это супер-субъективно), не думаю, что смог бы там комфортно жить.
всё так. но обособленность ≠ полная изолированность. буквально в вашем же примере вы запрещаете домену лезть в соседний домен, но разрешаете это делать бизнес-процессу. отсюда получаем дополнительный уровень бизнес-процессов. бизнес-процессы, в вашем понимании, тоже должны быть изолированы друг от друга? или один большой бизнес-процесс может переиспользовать другой более мелкий?
зависит от ситуации. вы сами пишете, что ddd — это «про перенос бизнес логики, как она есть, в код». если в реальном мире логика сложного бизнес-процесса в том, чтобы полностью переиспользовать несколько мелких бизнес-процессов, то дублирование реализации в коде — это костыль, не отвечающий реальному бизнес-процессу и нужный только для преодоления искусственного ограничения в архитектуре. если же в реальном мире кусок логики сложного бизнес-процесса просто повторяет имеющийся мелкий бизнес-процесс, но не переиспользует его (например, за этот кусок и за мелкий бизнес-процесс отвечают разные подразделения), то дублирование в коде отвечает реальному бизнес-процессу.
ничего страшного, это вопрос только времени и опыта. в простой пример с партнёрским кодом вы уже воткнулись, и это привело вас к идее выделения второго уровня (бизнес-процессы). воткнётесь и в более многоуровневую вложенность. проблема лишь в масштабировании: ваш вариант из статьи сейчас фиксирует ровно два уровня (бизнес-процессы и доменные методы) в том числе и для тех ситуаций, когда это избыточно, и для тех, когда этого мало. а композиция позволила бы намазывать ровно то количество слоёв, которое требуют реальные бизнес-процессы (где-то это будет всего один слой и достаточно одного домена, где-то — два, как у вас в статье, а где-то — больше).
вот именно появление if-ов и будет очень наглядным сигналом к тому, что бизнес-процессы стали различаться и пора рефакторить: у вас теперь createPartner() не использует стандартный addClientToPartners(), а добавляет в список партнёров как-то иначе. и это нормальная реакция кода на изменение бизнес-процесса в реальности.
лично я бы тут винил представителей немного других профессий, а не разработчиков. но боль ваша понятна, да.
хм, разве? не улавливаю этого в своём предложении. я, наоборот, за упрощение. и предлагаю вместо трёх видов сущностей оставить, грубо говоря, один. концептуально тут тоже просматривается аналогия с ФП и ООП. там где вы предлагаете методы, классы и модули (каждый со своими ограничениями), я предлагаю всё тупо считать функциями и позволить разработчику конкретного приложения собирать из этих функций такого франкенштейна, которого нужно для его конкретного приложения.
Встречная идея такая: как насчёт отказаться от иллюзорной независимости доменов и разрешить себе композицию доменов и/или доменных методов? Надо же чему-то хорошему у функциональщиков учиться.
• У вас в реальности есть юз-кейс создания клиента — реализуем его в коде доменным методом createClient().
• У вас в реальности есть юз-кейс добавления существующего клиента в партнёры — доменный метод addClientToPartners().
• И у вас есть юз-кейс создания клиента-партнёра, который является композицией предыдущих двух, — оформляем его в виде доменного метода createPartner(), который использует createClient() и addClientToPartners().
Да, получается, доменный метод createPartner() в этом случае зависит от двух других доменных методов. Ну и ничего страшного, потому что и реальный юз-кейс зависит от двух других. Наличие таких зависимостей не делает доменный метод новой сущностью (бизнес-процессом). Это всё ещё просто доменный метод, к которому мы можем прибивать порты. И, да, порты могут быть прибиты в этом примере к любому из трёх доменных методов (хоть к атомарным, хоть к композитноум), потому что все три юз-кейса существуют в реальности и могут работать по отдельности. И, да, нужда в группировке доменных методов в домены вроде как отваливается, потому что каждый публичный доменный метод, реализующий свой юз-кейс (хоть атомарный, хоть композитный) — это и есть как бы самостоятельный маленький домен.
Другими словами, идея в том чтобы в общем случае отказаться от разделения на доменные методы, домены и бизнес-процессы (потому что эти три этажа иногда будут избыточными, а иногда их будет недостаточно) в пользу композиции доменных методов произвольной вложенности, и вложенность будет зависеть от реальной сложности разрабатываемой системы: если у вас в реальности нету сложных составных юз-кейсов, их не появится и в коде, вся система будет состоять из несложных атомарных доменных методов; если же у вас много длинных составных процессов, состоящих их других процессов, состоящих из других процессов и так далее, то вы можете это всё накомпозировать, не придумывая новые сущности и новые соглашения для каждого нового уровня вложенности.
То есть, внизу адаптеры, а над ними — граф юз-кейсов, к которым сверху прибиты порты.
Понятно объяснил? Покритикуйте.
Чиня себе дофаминовый цикл с помощью креативненьких реализаций стандартных вещей, вы ломаете дофаминовый цикл любому, кто будет читать этот код после вас (включая вас самого через полгодика).
ну так это ж, получается, просто проектная разработка (в противовес принятой в skyeng продуктовой)
Тут очень сильно зависит от того, какой запрос (и майндсет) у продакта. Если он приходит с вопросами «через сколько времени такая-то задача будет на проде», то твоя идея (и канбан) работает хорошо. Если он приходит с вопросами «какие фичи будут через неделю на проде», то хорошо работает скрам. Если продакт мыслит потоком отдельных плюс-минус изолированных задач — канбан. Если еженедельными инкрементами — скрам.
Во-первых, я хорошо обучен программировать, а управлению людьми я никогда нигде не учился. И мой внутренний перфекционист против того, чтобы делать что-то, за что берёшься, плохо. Но тут работодатель пошёл на встречу и отправил на обучение, дал возможность подтянуть менеджерские навыки, а заодно поглубже заглянуть в профессию и увидеть, что ждёт впереди. И то, что я увидел, мне не понравилось. Я в какой-то момент отчётливо понял про себя, что я всё-таки ремесленник, а не управленец — мне интереснее делать вещи, а не управлять людьми, которые делают вещи. И уж тем более не управлять людьми, которые управляют людьми, которые делают вещи.
Во-вторых, мои интересы в жизни не ограничены пределами работы и профессии. И поэтому для меня во многом решающим стало опыт друзей и знакомых, продвинувшихся или продвигающихся по карьере управленцев. Когда один из них в разговоре со мной с гордостью заявил, что, мол, ура, за прошедший год он достиг очень важного для себя результата: научился работать всего 11 часов в день, — я понял, что ну её нафиг такую работу и такую карьеру, это не мой путь. Буквально на прошлой неделе у меня состоялся похожий диалог с одним знакомым, занимающим в своей компании должность типа CTO, который рассказал, что работает 75 часов в неделю. Я тупо не хочу посвящать работе столько времени, мне есть на что ещё потратить свою жизнь.
В некоторых местах, до куда прогресс в виде AirBnB ещё не дошёл, имеет смысл снять на букинге номер на первую неделю, и искать постоянное жильё уже на месте. Это касается Азии, прежде всего. Но даже в Азии иногда срабатывает вариант с фейсбуком (например, прямо сейчас мы живём на Самуи в доме, о котором договорились через фейсбук).
Район выбираем примерно так. Если город новый и хочется его посмотреть — поближе к цивилизации и к тому, что хочется посмотреть. Если не новый и уже обзавелись друзьями — поближе к друзьям.
Перечитал написанное, и как будто слишком общо ответил. Если у вас какие-то более конкретные вопросы, например, про конкретные города — задавайте.
В Малайзии был, но мельком — на несколько дней летал в Куала-Лумпур на визаран из Таиланда. Столица оставила очень неприятные впечатления (но это супер-субъективно), не думаю, что смог бы там комфортно жить.