DDDevotion

Сейчас практически все компании внедрили практику System Design Interview. Наверное большинство так или иначе сталкивались с такими собесами. Если коротко: дают задачу, надо спроектировать примерно как будет выглядеть система для решения задачи.

В сети много мануалов, видео, мок-интервью и прочих материалов. Обычно советы сводятся к следующему:
1. Не бросайтесь сразу что-то делать, осмотритесь, разметьте территорию.
2. Проясните неясные моменты или сами явно проговорите какие-то допущения-предположения. Какая нагрузка, что можете, а что не можете использовать, какие ожидания по консистенси и тп. Что-то неясное можно припарковать (тоже явно сказав об этом).
3. Опишите какие блоки вы видите.

Лучше все это делать с шаренным экраном и фиксировать в miro/unidraw — так и вы не забудете, что о чем-то договорились, и интервьювер лучше поймет куда и как вы идете.

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

1. Event Storming — куда без него. На одном из интервью я провел миништорминг сессию: прям накидал перед собой события которые есть в системе, отметил системы, людей, наметил границы. Собственно этой сессией я закрыл перечисленные выше пункты. не обязательно упарываться, можно начать просто с событий, это уже даст некоторую базу.
2. Домены. Если вы видите, что задача включает в себя generic и supported домены, то можно сразу сказать, что вы не планируете это проектировать в рамках интервью, вы возьмете готовый продукт или известную реализация и просто заиспользуете. Например вы не будете писать свою аутентификацию. Повторюсь еще раз — важно все проговаривать вслух, возможно вы не заметили какое-то особенное требование и то что вы считали генерик доменом, на самом деле кор. Нормальный интервьювер вам подсветит, что ваше допущение не ок.
3. Все усилия на core. После того как мы отсекли генерик домены, остался кор — его и будем проектировать. Возможно вы заметите два кор домена, контексты и прочее, что вас подтолкнет к созданию распределенной системы (ака микросервисы).

Где и когда использовать:
Если в компании практикуют DDD (или хотя бы в описании вакансии были эти буковки), то такой подход может вам набрать дополнительные плюсики. Будет понятно, что вы написали про Domain-Driven design в резюме не просто так, а регулярно используете в реальной жизни.

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

А какой у вас опыт использования DDD на собеседованиях? Спрашиваете ли вы сами как интервьюеры? Как относитесь к кандидатам с DDD бекграундом?

www.tg-me.com/us/DDDevotion/com.dddevotion/421

1.8K viewsJun 24 at 07:27

Сейчас практически все компании внедрили практику System Design Interview. Наверное большинство так или иначе сталкивались с такими собесами. Если коротко: дают задачу, надо спроектировать примерно как будет выглядеть система для решения задачи.

В сети много мануалов, видео, мок-интервью и прочих материалов. Обычно советы сводятся к следующему:
1. Не бросайтесь сразу что-то делать, осмотритесь, разметьте территорию.
2. Проясните неясные моменты или сами явно проговорите какие-то допущения-предположения. Какая нагрузка, что можете, а что не можете использовать, какие ожидания по консистенси и тп. Что-то неясное можно припарковать (тоже явно сказав об этом).
3. Опишите какие блоки вы видите.

Лучше все это делать с шаренным экраном и фиксировать в miro/unidraw — так и вы не забудете, что о чем-то договорились, и интервьювер лучше поймет куда и как вы идете.

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

1. Event Storming — куда без него. На одном из интервью я провел миништорминг сессию: прям накидал перед собой события которые есть в системе, отметил системы, людей, наметил границы. Собственно этой сессией я закрыл перечисленные выше пункты. не обязательно упарываться, можно начать просто с событий, это уже даст некоторую базу.
2. Домены. Если вы видите, что задача включает в себя generic и supported домены, то можно сразу сказать, что вы не планируете это проектировать в рамках интервью, вы возьмете готовый продукт или известную реализация и просто заиспользуете. Например вы не будете писать свою аутентификацию. Повторюсь еще раз — важно все проговаривать вслух, возможно вы не заметили какое-то особенное требование и то что вы считали генерик доменом, на самом деле кор. Нормальный интервьювер вам подсветит, что ваше допущение не ок.
3. Все усилия на core. После того как мы отсекли генерик домены, остался кор — его и будем проектировать. Возможно вы заметите два кор домена, контексты и прочее, что вас подтолкнет к созданию распределенной системы (ака микросервисы).

Где и когда использовать:
Если в компании практикуют DDD (или хотя бы в описании вакансии были эти буковки), то такой подход может вам набрать дополнительные плюсики. Будет понятно, что вы написали про Domain-Driven design в резюме не просто так, а регулярно используете в реальной жизни.

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

А какой у вас опыт использования DDD на собеседованиях? Спрашиваете ли вы сами как интервьюеры? Как относитесь к кандидатам с DDD бекграундом?

BY DDDevotion