Thread by @jsunderhood

Теперь немного о собственно проектировании.

Допустим, мы знаем, что нашему проекту _нужна_ суровая масштабируемость. Что делать?

Первым делом стоит взять ручку, бумажку и пойти «программировать ногами» 😃

https://twitter.com/lizuschiykotik/status/1386598613242023940

Мы (люди) плохо умеем прогнозировать будущее. Проектирование систем — это прогнозирование будущего.

Чем больше исходных данных мы насобираем, тем больше вероятность, что мы правильно составим «карту территории».

(О соотношении карты и территории: ru.wikipedia.org/wiki/Соотношен…)

Что нам необходимо знать?

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

Чего мы хотим добиться:

- Доменный слой должен быть самостоятельным и независимым.
- Адаптеры должны подстраивать внешние сервисы под нужды нашего приложения, а не наоборот.
- ...

- ...Кода должно быть минимальное необходимое количество.
- Модель системы должна быть максимально простой.
- Направление зависимостей должно быть _к домену_.

Я недавно писал пост о дизайне системы с помощью слоёв и DDD:
bespoyasov.ru/blog/generatin…

Давайте используем его как пример и ответим на вопросы.

Так-с, обед закончился 😅
Ответим на вопросы после работы!

Продолжим 🙂

На какие вопросы мы ищем ответы? В первую очередь — какие перед нами стоят задачи. Потому что ответ на этот вопрос определит, что будет содержать доменный слой.

Кроме этого — какое решение мы посчитаем достаточным, какая требуется глубина проработки.

Если мы делаем приложением только под браузер — это одно, а если мы пишем его для браузера, React Native, и Ноды — уже другое.

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

Во втором случае наоборот.

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

Тут, наверное, надо сказать ещё, что при дизайне систем надо подубавить динамик перфекционизма, потому что перфекционизм мешает 😃

Невозможно проработать систему на 100%. Всегда останется что-нибудь, что можно улучшить.

Это стоит иметь в виду, когда мы взвешиваем выгоды и издержки.

При непосредственно дизайне я люблю сперва проектировать домен. Обычно я беру бумажку с ручкой и рисую квадратики со стрелочками 😅

Получается такой UML на минималках.

В стрелочках я указываю публичное API, возможно, абстрактно формат сообщений, которыми сущности будут обмениваться.

Когда примерно картинка складывается, я раскидываю модули на слои и проверяю:

- ...

- ...Всё ли нормально с направлением зависимостей;
- Следую ли я принципам SOLID;
- Что будет, если захочу заменить реализацию какого-то модуля на другую;
- Сколько понадобится ресурсов, чтобы поменять платформу, инфраструктуру, whatever.

Обычно получается нечто вроде такой диаграммы (из поста с деревьями):

Я не стал упарываться, покрывая веб-платформу адаптерами с ног до головы, так как был уверен, что мне это не понадобится.

Но зато при проектировании я заметил, что модуль геометрии придётся разбить на 2 отдельных интерфейса.

ota-solid.now.sh/isp

Также помогает выделить Driver (управляющие), и Driven (управляемые) адаптеры:

(На эту тему ещё раз посоветую эту статью herbertograca.com/2017/11/16/exp…)

Диаграмма помогает не писать сразу код, а сперва приметиться на бумаге — «а оно вообще поедет?».

Иногда диаграммы помогают обнаружить ошибки проектирования:

- функциональность засунули не туда;
- модули слишком сильно зацеплены;
- ...

- ...Нужна шина событий, чтобы связать какие-то сущности;
- Нарушаем SRP, DIP, ISP и прочее.

Если паровоз на бумаге поедет, то можно думать в сторону кода.