Vadim Zhivotovsky
"RabbitMQ подходит...когда нужна... более зрелый подход к стандартной очереди задач"
Что такое "зрелый" подход? Можно критерии зрелого подхода?
Я немного запутался.
Процесс обмена сообщениями в Kafka:
4. ...Kafka не отслеживает, какие сообщения были обработаны консьюмерами.
6. В случае успеха офсет помечается как закоммиченный и сохраняется в специальном топике. В случае ошибки оффсет сбрасывается на предыдущее значение или на дефолтное.
Т.е., раз помечает и сохраняет результат обработки, отслеживает?
Если мы про конечную цель, то - удовлетворение бизнес-целей, а не создание ИС. ИС - способ, а не цель. Об этом нельзя забывать.
Продуктом "изучения предметной области и выявления требований" являются выявленные потребности (я там ошибся словом, это важная ошибка), а не ТЗ.
Уже на основании анализа потребностей принимаются решения о способах их удовлетворения. И в ТЗ попадёт далеко не всё.
Опять же, в ТЗ нет места вопросам.
Данное определение ТЗ - очень весёлое, где ещё такие смешные вещи на досуге можно почитать?
Потому что ТЗ не про общение и создание "абстрактного элемента" (извините, тут совсем ржу-немогу), а про конкретное, неожиданно, техническое задание. Которое (если нет ЧТЗ) можно оценить, спланировать по всем ресурсам, протестить и т.п. (можно применять методы проверки требований)
Ну, если хочется формулировками покидаться, что лучше уже в ГОСТ посмотреть, там гораздо точнее и грамотнее.
Поэтому и говорю, что вы не понимаете, что такое ТЗ. Подменяете его другими артефактами
Ещё раз: "красиво и грамотно". Если заказчик не может читать ваши доки, значит, ваш вопрос решён неграмотно
Навскидку.
1. Есть такая аксиома - ни одна графическая модель не может полностью отобразить содержание. Поэтому что вы сделали? Да, забухали кучу текста в картинку и на голубом глазу назвали это "графическое ТЗ"
2. Наверное, вы не понимаете, что такое ТЗ. На чёрной картинке у вас не ТЗ, а изучение предметной области, выявление требований
3. Ну и тут уже выше сказали, вы изобрели монструозный велосипед. Есть исчерпывающие наборы нотаций, красиво и грамотно решающие ваши вопросы
4. Выбранный стиль подачи материала не каждому зайдёт. Восторженный пафос в форме "мы красавчики" (нет, см. выше) и рекламы своей компании (вызывает отталкивание)
Не понял смысла статьи. Галопом по европам, сплошные общие фразы и банальности, выдранные из таких же тысяч статей. Ничего абсолютно нового.
И да, для вас, наверное, будет новостью: именно заказчику от именно команды разработки - в общем случае, ничего не нужно. Подумайте, почему. Вы ж аналитик, а не копипастер?
Аналитики и разрабы должны, обязаны быть внутри одной терминологии
Не понял описание 1-го паттерна.
Если "Model — это бизнес-логика", то "Controller... содержит основную логику" чего, какой? Вообще всей? Тогда как бизнес-логика оказалась в Model, если тут вся "основная"?
Если мы вводим классификацию чего-то (логики), то необходимо в каждом случае следовать своей же классификации