Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
В данной статье хочу рассказать о приеме, который поможет грамотнее спроектировать приложение (да и не только приложения, но об этом в другой раз), даже если вы не сильно владеете общеизвестными архитектурными принципы типа SOLID и прочих. При этом отмечу сразу, что я не предлагаю здесь какие-то новые принципы - это скорее лишь следствие их и просто прием, который позволит следовать как минимум части из них естественным образом.
На самом деле под “переводом стрелок” имеются в виду сразу два подхода, и по очереди о них расскажу. Также отмечу, что приемы эти не является какими-то ноу-хау, и более-менее опытные разработчики пользуются ими "на автомате". Но полагаю, если сформулировать их в явном виде, это будет полезно для менее опытных специалистов или даже вообще начинающих.
Начну сразу с примера. Представим, что у нас есть некий интернет-магазин, и flow покупки в нем вполне стандартный: пользователь на сайте наполняет корзину и оформляет заказ. Далее пользователю необходимо этот заказ оплатить, после чего менеджеру прилетит уведомление на почту. Все просто для простенького магазина. Если представить этот порядок действий визуально, будет примерно так:
А суть приема (первого его воплощения) предельно проста: реализуя эту логику, представить мысленно (или так же на бумажке), как у каждого из этих узлов появляются дополнительные стрелки, как входящие, так и исходящие. Или если быть точнее, не просто их представить, а задать себе вопрос: насколько разрабатываемое приложение к этому будет готово?
Взять, к примеру, входящую стрелку к “Корзине”. В текущем варианте корзину наполняет просто сам пользователь. И наша задача представить, что таких входящих стрелок может быть несколько. В общем случае нам даже неважно, что это именно будут за стрелки (абстрагируемся от этого), но полезно и пофантазировать. Например, в будущем корзину должен будет уметь наполнить не только сам пользователь, но и менеджер за него. И вполне вероятно уже даже не через основную “морду” магазина, а через отдельную админ-панель.
При этом тут важно понимать: сейчас, пока мы лишь мысленно это представляем, не нужно реализовывать эти сценарии (и уж точно не нужно уже сейчас пилить админ-панель, если ее еще нет