Comments 24
Может где-то и есть источник, в котором также лаконично описано всё, что связано с построением архитектуры приложения, но мне он на глаза не попадался. Статья торт. Жду продолжения.
есть паттерн "main bus" для факторио
Собственно да. По сути это тот же монолит, но гораздо легче масштабируется и решает большую часть проблем. Интересно, увидим ли в "микросервисном" подходе кучу квадратов 200*200 разделённых железкой, что является вторым типичным масштабируемым решением.
Так есть же такое решение, видел на ютубе, там парень делал клетки не помню какого размера и они были все соединены железкой. Но есть пара нюансов : он это делал в режиме песочницы и делал он это долго. Но теперь с этими чертежами можно свою базу построить. Опять же, пропускная способность ограничена железкой (выше чем у конвееров, но всё же ограничена)
А жуки это походу девопсы прибегающие на слишком прожорливую архитектуру по ресурсам.
А какие архитектурные стили используют спидранеры?
Ну то что я на ютубе видел - это пожалуй монолит на коленке. Причём, часто после того как завод произвёл нужное количество вещей, его тут же переделывают под другое производство. Т.е. живая разработка сразу на продакшене.
У спидраннеров заранее есть чёткий план, что и когда производить. Причём этот план от одной попытки спидрана к другой дорабатывается.
Архитектура близка к монолиту, от него остаются только сильные стороны. Недостатки компенсируются тем, что всё заранее посчитано и учтено.
Есть мнение, что запуск ракеты - это только MVP.
А вот дальше вылезают недостатки проектирования, так как, чтобы увеличить производство одних компонентов, нужно увеличить и для промежуточных.
Становится проще снести всё и построить заново с учетом новых требований, чем протянуть ещё один конвеер через имеющийся клубок макаронин.
Либо за несколько проектов нарабатывается опыт, и место для расширения выделяется заранее.
ПС. The factory must grow
Архитектура из микросервисов ситиблоков наше всё!
Я подумал над этим и понял, что нет.
В таком понимании обыграть будет сложно ситуацию:
Исследования - после запуска ракеты новые исследования не добавляют в игру новых сложностей, а просто делает "Сильнее, Выше, Быстрее". В общем, это уже не наполнение продукт фичами, а больше оптимизация на этапе эксплуатации. Не более.
Цель - если конечная цель не запуск ракеты и переход на АЭС, то тогда неизвестно что сделать взамен. Разрастись на определённое количество кв.км? Достичь определённой скорости производства? хз.
Я сейчас делаю SOA и скажу, что уже посреди сюжета хорошо видны плюсы и минусы Архитектуры, хотя и высчитать их в цифрах мне ещё предстоит. В общем, подход работает, а значит смысла менять что-то нет.
Желаем автору терпения для реализации следующих паттернов.
"Главная шина" — это тот же монолит, но с хорошей архитектурой.
Многоблоковая база на основе LTN — это микросервисы. ЖД сеть тут играет роль MQ, а LTN — оркестратор :-)
На самом деле, статья "может получиться хорошим обучающим материалом" и для начинающих разработчиков.
Это интересно, применять серьезные подходы к проектированию в, на первый взгляд, простых играх.
На днях вернулся в игру чтобы попробовать реализовать микросервисную архитектуру. Отладка жд путей одно удовольствие!
Жду продолжения.
ждем продолжения
Проверяем Архитектурные стили на движке Factorio (часть 1)