Ответы пользователя по тегу Проектирование программного обеспечения
  • Что значит Domain Driven Design?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    домен здесь означает предметную область знаний, эти знания (понимание процессов), являются основными при разработке.
    Тоесть никаких придуманных разработчиком абстракций, всяких там абстрактных модулей, факториКонструкторМенеджеров и тд, все максимально предметно и максимально приближенно к тому как реально процессы в компании работают.
    Если например разрабатывать систему учета в ресторане по ДДД, то в ней будет полностью скопированна структура самого ресторана, с названиями должностей, позиций, и процессов, без всяких там абстратных слоев и "удобных" нововведений. В итоге продукт получается сразу же понятный и привычный пользователям.
    Ответ написан
    2 комментария
  • Какие существуют методики и инструменты для масштабируемости проекта?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    масштабировать компоненты - будет эффективнее -> тк нагрузка на компоненты всегда не равномерная, какие-то более нагружены какие-то менее.
    >Создать несколько одинаковых бэков на разных серверах
    оба варианта рабочие, но нужно помнить что при разделении компонентов или разделении бэков, они не должны зависеть от одного источника данных (одной БД), иначе все опять упрется в производительность одной БД.
    Для этого можно использовать базы поддерживающие разделение через Ключ->Значение (типа Касандры), и которые тоже в свою очередь по серверам масштабируются
    Ответ написан
    Комментировать
  • Недостати при комбинации нескольких команд во время одного запроса/процесса в CQRS подходе?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    >обработчик активации аккаунта если почтовый адрес от gmail?
    не вижу никаких проблем чтоб обработчик, в этом случае, сам создал команду на активацию эккаунта.
    >Лично я вижу 2 варианта на проектирование комманд
    рабочая схема, но вы начинаете множите сущности там где этого особо и не требуется, заставьте свой сайт использовать тотже самый апи, который будут использовать сторонние сервисы, и сделайте его единым для всех.
    Мне кажется неплохо было бы разделить действия "запроса статьи" и "получения рекомендаций к статье".
    Ответ написан
    Комментировать
  • Как разбить транзакцию по микросервисам сохранив консистентность данных?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    то что вы описали называется двухФазным комитом, раньше очень часто использовался.
    сейчас активнее используют похожий но немного другой подход, тоже связанный с тем что резервируют определенные ресурсы (например деньги на счету, и товар на складе) потом проверяют промежуточный статус операции, и потом проводят и подтверждают операцию - разница в том что ничего не перезаписывается а непрерывно все запросы логируется, и любые откаты операции идут через добавление новых записей-запросов в лог (он же и очередь сообщений)
    ----
    там много тонкостей, например вы говорили про время-метки, в целом метки времени добавляют - если нужно контролировать очередность промежуточных шагов (но обычно это не так важно, поэтому метку времени не всегда добавляют), но добавляют уникальный айди операции, тк в случае сбоя запроса (при например длительном ожидания ответа), может произойти "переотправка" запроса, и нам эта метка с уникальным айди позволяет не дублировать одну и туже операцию.
    =====
    есть тонкости например с тем, каким образом разделены эти микросервисы, может это просто дублирование одного и того же сервиса но например каждый из них обрабатывает запросы от разных сегментов пользователей, поэтому не требуется согласовывать какие-то операции между этими микросервисами.
    ====
    на мой взгляд - это вобще разводные вопросы не имеющие правильного ответа, схемы подбираются конкретно под проект и задачи, тем более если вы не разрабатывали какую-нибудь платежную систему, типа яндекс.денег то вообще бесполезно что-то обсуждать.
    это не камень в ваш огород, этим вообще обычно мало кто реально занимается, уверен те кто у вас это спрашивал сами мало что в этом понимают, а спрашивают такие вещи чтоб вас слить.
    Ответ написан
    3 комментария
  • Какие достоинства хранения шаблонов в БД?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    производительность БД выше чем у файловой системы
    Ответ написан
    8 комментариев
  • Меняем архитектуру проекта на распределённую - с чего начать?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    >Bind user to node after login
    что первый вариант что этот - не очень решения при распределенной архитектуре.
    ====
    вам нужно переделать мышление, о том как вообще следует выстраивать работу в распределенных архитектурах.
    но ничего страшного, можно начать с курсов на курсере или что-нибудь в таком стиле посмотреть
    потом можно говорить о каких-то конкретных подводных камнях.
    Ответ написан
    1 комментарий
  • Как не переборщить с желанием все спроектировать прежде чем писать код?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    >не нравится как он написан
    пффф а ты что думал, в сказку попал? тебе и не должно нравиться, это для бизнеса где-то на 25 месте находится.
    -----
    чесно говоря я вообще не слышал чтоб реально на практике УМЛ использовали, для проектирования (хотя тема когда-то и была на хайпе).
    Ну да на черновиках набрасывают общие идеи, сам код также может быть тем черновиком для идей, но это всего-лишь черновик.
    =======
    >"Давай декомпозируем на задачи и начнем делать. По ходу реализации разберемся"
    очень грамотный, взвешенный подход. Основная проблема не опытных людей, попытка сразу выдать идеальный результат в вакууме, люди которые поопытнее знают что это сделать не возможно, а попытка идеальной проектировки приведет только к переусложнению и ухудшит разработку и вместо того чтоб гибко подгонять решение под постепенные уточнения, вы будете стремится все подогнать под рамки какой-то первой "идеальной" идеи реализации, на основе первого восприятия задачи (которое часто ошибочно).
    Ответ написан
    Комментировать
  • В каких случаях стоит прибегать к использованию архитектурных подходов?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    Уверен в начале нужно делать максимально просто, максимально примитивно и только ПОСТЕПЕННО развивать продукт, и только ТАМ где это надо.
    Ни в коем случае нельзя заниматься оверинженерингом, возможно на следующей итерации вообще половина функционала будет выкинута и в совсем другом направлении будете развиваться, а даже если не выкинута, то будете пересматривать саму модель данных, схемы взаимодействия и тд.
    Такие вещи должны постепенно рождаться отвечая вашим потребностям. Не нужно внедрять подходы или технологии (какие-то слои) только для того чтобы внедрить. Нужно точно отвечать на вопрос ЗАЧЕМ, и ПОЧЕМУ вы это внедряете, пока нет на эти вопросы ответа, значит такой подход или технология не нужна.
    Соответственно если вы спрашиваете надо ли вам это делать -> ответ однозначно нет. Пока вы сами не дорастете до понимания где и зачем это надо делать.
    Ответ написан
    Комментировать
  • Кто подскажет ответ по ряду вопросов?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    для улучшения поиска коллизий полно алгоритмов, обычно они ориентированны на то чтоб "ПОЛЕ" разделить на сектора, и искать коллизии только внутри точек с общими секторами.
    в рамках микросервисной архитектуры каждый "микросервис" может обслуживать свой небольшой сектор.
    ваша задача найти выгодную схему нарезания на сектора, предположу что нужно будет использовать алгоритм хэширования (разделения на сектора) с двумя переменными такие как (размер и расположение сектора и его средняя загрузка, чтоб в среднем была равная загрузка секторов на обработку данных), наилучшую формулу вам нужно будет найти опытным путем.
    есть само собой и другие подходы.
    не вижу какой-то необходимости что-то с пользователями кэшировать. Лучше обеспечте локальность данных, тоесть размещайте данные (БД) в том же самом месте где их и обрабатывайте, это главное правило для масштабируемой и производительной архитектуры построенной на микросервисах.
    Ответ написан
    Комментировать
  • Какую оптимальную архитектуру выбрать?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    ты не можешь кэшировать работу логики приложения -> тк ты сталкнешся с тем что кэш не соответствует реальной модели данных, и это приводит к ошибкам в сервисе (погугли инвалидация кэша), в итоге чтоб тебе держать кэш корректным тебе нужно будет еще больше нагрузки проводить и сверять корректность кэша с данными в БД.
    так что про кэширование логики забудь, кэширую простые готовые ответы пользователю, не поболее того.
    1. Для гиганского ускорения (в тысячи раз) тебе нужно перенести модель и логику в оперативную память, а для этого забыть про всякие там ноды хуеды, а перейти на статически типизированные компилированные языки, и уже эту модель данных в памяти асинхронно сохранять в базу данных, тогда все летать будет.
    2. Для легкой и самое главное корректной разработки сервиса с большим количеством "событийных" зависимостей - желательно использовать "Функциональное реактивное программирование" (в гугле поищешь материалы почему и как это реализуется)
    Ответ написан
    Комментировать
  • Связанные ресурсы REST API?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    нет какой-то жесткой спецификации.
    оба варианта подходят, и несколько вариантов тоже подходят)
    Ответ написан
    Комментировать
  • Какую архитектуру использовать для новостного агрегатора?

    angrySCV
    @angrySCV
    machine learning, programming, startuping
    для управления потоками, а также планированием задач удобно использовать например akka
    Ответ написан
    Комментировать