Team Lead это не значит что человек исключительно руководит, он также пишет код и является исполнителем. Суть в том, что есть один человек который понимает в разработке и несет полную ответственность за конечный результат. За это и имеет вознаграждение побольше остальных.
Уроков нет, но есть исходный код подобного проекта https://github.com/multitheftauto/mtasa-blue можно наверняка разобраться как это устроено если знать C++, в ридми у них сказано что основано это на внедрении кода как тут выше уже упоминули.
Так прозвали книгу описывающую 23 классических шаблона проектирования. Она была написана четырьмя авторами, которых прозвали "банда четырех", соответственно некоторые называют эту книгу "книга банды четырех" поскольку официальное название книги довольно длинное и сложное к запоминанию/написанию.
Это наиболее распространенные шаблоны. Остальные используются намного реже. Человеку который изучает паттерны советую книгу паттерны проектирования от фрименов. Можно найти бесплатно в интернете. Я начинал с неё. Правда сейчас есть переиздание от 2018 года и оригинал от 2011 года. Я читал от 2011 года - отличная книга, много изображений, легкая в понимании. От 2018 года не читал, поэтому сказать нечего.
Абсолютно такая же мысль посетила при прочтении, что первое, что нужно сделать перестать использовать ассоциативные массивы для описания состояния объекта, а использовать для этого собственно сами объекты.
У нас сразу дают писать/верстать новые компоненты или фиксить/добавлять что-нибудь в уже существующих. В общем всё тоже самое что делают и все остальные. Просто потом кто-нибудь ревьювит такой код прежде чем его смержить и объясняет новичку что, где и почему не так и что нужно переделать. Так человек постепенно вникает, как и что принято здесь делать. Сроки двухнедельные спринты, но если не успевает ничего страшного, просто доделает позже. Главное - это чтобы хоть какой-то прогресс был в задачах в нужном направлении.
Ну и совсем в первые дни задач не дают, объясняют, что за продукт, показывают как работает, объясняют какие-то основные моменты и дают человеку время поковырять, посмотреть код как там что устроено.
Алиса Соколова, ну то есть это работает примерно так, крупные интернет-провайдеры заключают соглашение о создании точки обмена трафиком. Подключают к ней свои сети. К точке пускают международный канал связи соединяющий данную точку обмена трафика с точкой во внешнем мире. И так далее до корневой.
Автор верно подметил про согласованность данных. Об этом изначально думать нужно как это будет. Как правило в таких системах используют saga и получается eventual consistency, когда данные не консистентны сразу, но станут таковыми через N времени. Но требуется еще и некое подобие изолированности из ACID. Если сущность в текущий момент участвует в незавершенной саге, то никто другой не должен иметь возможности её изменять. Иначе всё сломается. Вот первичные вопросы. Толку от деления если не будет консистентности данных. Тут вон уже про реакт начали писать. Видимо это самое важное в микросервисах какую хрень выбрать для визуализации. Ну вообщем как обычно на тостере, советчики из тех кто сам ничего подобного не сделали и у которых всё просто. Советы из разряда разбей свой код и готово )))
Я бы в read моделях вообще не использовал ORM. Оно там не нужно, нам нужно просто получить данные и пробросить их дальше, а для этого достаточно обычных sql запросов. И вообще это чтение может быть с какой-нибудь денормализованной базы данных подготовленной специально для чтения, чтобы не городить трехэтажные селекты. Вот для write моделей, да это нужно, но там и не нужны сложные sql запросы потому что не вытаскивают связи вместе с объектом. Вытаскивают только сам объект, меняют его состояние и сохраняют обратно в хранилище. Если нужно поменять и связанные объекты в рамках одного и того же бизнес-процесса, то используют saga pattern и eventual consistency. В итоге получается распределенное приложение, с консистентностью данных, но без джойнов и транзакций. Ну и без РСУБД как правило, потому что пользы ноль от них в распределенных системах.
Максим Ковалев, погугли. Для чтения не используют репозитории и доменную модель. Это просто не нужно. При чтении делают прямые запросы в базу данных. Репозитории и доменную модель используют при изменении данных и здесь не должно быть сложных запросов, так как всё что требуется - это найти нужный доменный объект, изменить его состояние и сохранить обратно.
Где зарплата выше, там и расходы выше. Смысл ехать в Москву чтобы отдавать 40-50 за квартиру и иметь те же 50-60 и повышенные расходы на всё остальное.
2. Шашка это неотъемлемая часть доски. Поэтому модификация шашек будет из сущности доски.
У вас DDD указан в профиле. В книге Вон Вернона Implementing domain-driven design про агрегаты написано, что не нужно вкладывать сущность в агрегат просто потому что это кажется логичным. Нужно исходить из наличия инвариантов, то есть ситуации когда корень агрегата меняет своё состояние при изменении внутренней сущности, если такое есть - тогда да, если их нет, тогда нет. Здесь такого не наблюдается, стандартная ситуация из двух агрегатов доски и шашки со связью 1:N, где шашка ссылается на доску по id.
Вот что точно ненормально, так это отрисовка шашки, подсветка клетки, получить возможные ходы и тому подобное. Потому что это не бизнес-логика. Нет такого в игре в шашки, а когда проектируется что-либо, всегда нужно помнить, что мы делаем модель чего-либо. Соответственно чего нет в том предмете/явлении, который мы проектируем, этого не должно быть и в его доменной модели, так как модель есть упрощенная версия того или иного предмета/явления. Рисовать шашки, подсвечивать клетки и ходы - это всё должно быть в слое представления. Вообще автор может открыть выше указанную книгу и самостоятельно понять, что в его модели не совсем хорошо и как это можно исправить.
Алий Кунашев, есть такое. Тоже когда-то переходил с PHP 5 на nodejs 0.12 или даже раньше. Помню изначально скопировал с главной оф. сайта пример веб-сервера. Удивился ничего не сказать. Ничего не понял и стал читать доку к http модулю. Был в недоумении, как же так даже не рассказали как работает эта штука и сразу пихают API. Но я тогда просто проигнорировал гайды на оф. сайте и прочитал их много позже, а там всё это было и даже больше. Даже не знаю как освоил. Получается тоже через гугл.
Denis, в таком случае можно использовать паттерн composite. Базовая идея та же самая построенная на полиморфизме типов, как и практически все шаблоны проектирования.
Я лишь хотел донести мысль, что когда есть что-то одного и того же типа, но разной реализации - то это история про полиморфизм в любом случае. Шарики, ручки, доставки, кеши или логгеры - неважно. Важно лишь то, что мы должны отделить разные алгоритмы одного типа от клиента через интерфейс.
Alex Wells, да, всё верно, только в saga не откатывают, а компенсируют. Отличие в том, что rollback - это техническая штука, которая случается при ошибках в инфраструктуре. Компенсация - это бизнес штука, которая случается, если было нарушено бизнес-правило. Классический пример - бронь путешествия. На первом шаге бронируем отель, на втором шаге пытаемся купить билет на самолет, но сервис отвечает отказом, так как билеты на эту дату уже распроданы. Теперь требуется отказаться от бронирования отеля. Это и делает компенсирующая транзакция. То есть здесь нет технических ошибок, здесь есть только бизнес-правило не позволяющее дальше продолжать цепочку действий, поэтому она прерывается и начинает идти в обратном направлении. Соответственно компенсация - это не обязательно шаг строго обратный транзакции, в отличии от rollback. При технических ошибках, сага падает и остается не завершенной, такие ситуации нужно анализировать и исправлять код, чтобы сага всё же смогла придти к завершенному состоянию.
По поводу doctrine, я так понимаю имеется ввиду шаблон Unit of Work. Он к сожалению не решает проблемы дедлоков. Они в любом случае будут возможны. Чем больше сущностей внутри транзакции и чем чаще происходят эти транзакции, тем выше вероятность получить deadlock. Можно погуглить doctrine deadlock, чтобы в этом убедиться. Эту проблему не возможно решить какой-либо библиотекой, просто потому что так устроены сами ACID-транзакции. Doctrine может лишь скрыть эту проблему от пользователя используя например ретраи. Unit of Work просто позволяет не держать транзакцию открытой, а открыть её только в тот момент, когда мы готовы сделать коммит.
Но всегда, всё имеет свои компромиссы. Saga значительно повышает сложность проекта, но фактически является де-факто в распределенных системах.
semki096 всё верно websocket это web api, а не часть языка javascript. Node.js использует только javascript. Соответственно для того, чтобы поднять websocket-сервер вам нужно взять сторонний модуль или написать свой используя встроенные модули node.js. Например этот https://github.com/websockets/ws очень популярен или для вас проще сразу взять фреймворк https://github.com/socketio/socket.io так как там уже реализован протокол обмена данными между клиентом и сервером поверх websocket протокола.