Действительно в маленьких компаниях вероятность выстраивания теплой атмосферы намного выше. Там даже нет смысла в частых митингах, и не так много людей, которые будут отвлекать в чате (при условии, что у Вас реально подъемный уровень ответственности).
Моду подтвердить не могу, надеюсь, что так и есть.
Согласен. Глобальными перестройками никто не будет заниматься. Эта разработка похожа на концепт, чтобы все посмотрели и начали движение в выгодном для себя направлении.
Спасибо за идею. Эти технологии также действительно впечатляют. Они аппаратными средствами процессоров решают проблему медленной прослойки в виде ядра операционной системы. Добавлю еще один пункт со ссылкой на интересный обзорный материал, в котором они мелькают.
Заголовок действительно «желтоват». В статье, которую обсуждаем, имеется в виду не столько скорость (вычислений или передачи данных) процессоров, сколько проблемы устаревших концепций ядра операционной системы. Подумаю как можно уточнить название, спасибо.
В статье они о его упоминают. Говорят о том, что для доступа к I/O mmap — блокирующий интерфейс (в случае когда доступа к данным нет в страничном кэше). В ссылках дают статью в своем блоге ScyllaDB
К сожалению, однозначно сказать не могу, т.к. выбор подхода очень ответственная задача, без досконального выяснения всех требований её решать опасно. Если бы в функциональных требованиях была историчность, то CQRS/ES, многопоточность и реализация блокировок на уровне приложения.
Пример из статьи носит исключительно ознакомительный характер, чтобы описать быструю пробу концепции в экосистеме Laravel. Данная реализация, по моему мнению, достаточна наглядна. Что касается CQRS/ES для операций с деньгами, то она вполне оправдана в случаях, когда функциональные требования не будут нарушены особенностями реализации. С eventual consistency можно жить, если клиентам не придется мучительно долго ждать обновления проекций. Надеюсь правильно понял Ваш вопрос.
Интересная статья на эту тему от команды, которая на Elixir разрабатывает банкинг
В случае данной реализации, когда мы на HTTP запросы синхронно выполняем эти операции, — никак. И когда время расчета текущего состояния по событиям в агрегате будет ощутимым — могут начаться проблемы. Очередь для команд в агрегаты — решит проблему. Не пойму почему создатели примера использования этой библиотеки не учли это.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Моду подтвердить не могу, надеюсь, что так и есть.
Пример из статьи носит исключительно ознакомительный характер, чтобы описать быструю пробу концепции в экосистеме Laravel. Данная реализация, по моему мнению, достаточна наглядна. Что касается CQRS/ES для операций с деньгами, то она вполне оправдана в случаях, когда функциональные требования не будут нарушены особенностями реализации. С eventual consistency можно жить, если клиентам не придется мучительно долго ждать обновления проекций. Надеюсь правильно понял Ваш вопрос.
Интересная статья на эту тему от команды, которая на Elixir разрабатывает банкинг