Model-view-controller (MVC, «Модель-представление-контроллер») — архитектура программного обеспечения, в которой:
Модель данных приложения, пользовательский интерфейс и управляющая логика разделены на три отдельных компонента, так, что модификация одного из компонентов оказывает минимальное воздействие на другие компоненты.
Условие: У вас стоит задача на сайт выводить новости со стороннего источника. В другой команде есть скрипт, который забирает новости из этого источника и кладет её в базу данных, разработчик этой команды предлагает вам использовать реплику базы - то есть настроить реплику и читать данные со своего приложения.
Чем хорошо или плохо это решение, как вы предложили решить эту задачу?
Решение: Тут самым лучшим решением будет предложить разработку API команде с репликой. С версионностью и подпиской на этот API своей команде. Напрямую не стоит юзать чужую базу, так как любое изменения поля в таблице для их целей приведёт к проблемам у вас.
3. Горизонтальное и вертикальное масштабирование: чем они отличаются? Когда применять одно, а когда другое?
- Вертикальное масштабирование (Scale-up): Означает увеличение мощности и производительности системы путем добавления ресурсов на существующую физическую машину или сервер. Обычно включает увеличение процессорной мощности, объема оперативной памяти или добавление более быстрых хранилищ данных. Часто требует выделения больших финансовых средств на покупку более мощного оборудования. Прост в реализации, но может достичь ограничений физического оборудования.
Рекомендуется, когда есть монолитные приложения, которые сложно разделить на микросервисы или модули и требуют мощной вычислительной мощности. Когда лицензирование программного обеспечения основано на количестве серверов
- Горизонтальное масштабирование (Scale-out): Означает увеличение мощности и производительности системы путем добавления дополнительных физических машин или серверов в распределенную инфраструктуру. Обычно включает добавление новых узлов или серверов, которые работают параллельно и разделяют нагрузку. Не требует больших финансовых затрат на дорогостоящее оборудование, но требует управления и настройки распределенной инфраструктуры. Может обеспечить бесконечное масштабирование, поскольку новые узлы могут быть добавлены по мере необходимости.
Рекомендуется, когда есть потенциал для распределения нагрузки на несколько серверов или есть потребность в высокой отказоустойчивости и гибкости
Это методология разработки программного обеспечения для отображения знаний предметной области в программный код. Моделировать реального мира с использованием ООП для инкапсуляции бизнес-логики организации.
Предметная область(домен) - область знания или деятельности, в которой пользователь использует программное обеспечение. Простыми словами - это бизнес задачи и их окружение
Когда использовать?
- Используется когда большое количество бизнес логики
- Сложность предметной области превышает техническую сложность.
Когда не использовать?
- Когда техническая сложность превышает сложность бизнес логики
- Разработка бота, твиттера, мало бизнес логики
Преимущества
- Акцент на предметную область (понимания бизнес процессов, единая терминология)
- Командная разработка
- Шаблоны проектирования
Основные концепты DDD
Стратегическое проектирование
- Определение концепций
Эксперты, техническое задание, событийный штурм (оранжевые стикеры события, жёлтые агрегаты, фиолетовые бизнес условия, синие команды), материалы.
- Выработка единой терминологий
Описания модели предметной области. Это означает, что команда разработчиков последовательно использует этот язык во всех взаимодействиях и в коде.
- Определение границ поддомена
Ограниченный контекст
- Определение подобластей
Смысловое ядро, вспомогательные подобласти, универсальная подобласть
Тактическое проектирование
- Структурные элементы
Модули, структурное разграничение функциональности, обеспечиваю низкую связанность между разными функциональными частями.
Многослойная архитектура (Layered Architecture)
Идея изоляции каждой части ПО:
- Пользовательский интерфейс - Отображение информации пользователю и интерпретацию его команд
- Уровень инфраструктуры - Поддерживают более высокие уровни, а также поддерживает структуру взаимодействий между четырьмя слоями (вот почему хранилища находятся в этом слое).
Framework, Файловая система, Хранилища, Adapter, Port, Шина 3. Уровень приложения
UseCase, Handler, DTO
Службы
Инкапсулируют операции которые нельзя отнести к конкретной сущности или агрегату. Могут задействовать агрегаты
- Уровень домена - Представление концепций бизнеса, информации о бизнес-ситуации и бизнес-правилах.
Объекты-значения
Доступны по их значению, а не по идентификатору.Это неизменяемые объекты. Их значения не изменяются и не имеют жизненного цикла
Сущности
Доступны по идентификатору, представляющая набор свойств, которые имеют уникальный идентификатор. Сущность изменчива, потому что она может изменять свои атрибуты, а также имеет жизненный цикл, то есть ее можно удалить.
Агрегаты
Модель содержащее объекты предметной области, помогающая уменьшить количество двунаправленных ассоциаций между объектами.
Фабрики
Объектом, который отвечает только за создание других объектов.
Спецификации
Бизнес правила для проверки инвариантности сущности
CQS - означает разделение команд и запросов, принцип проектирования
Метод должен либо изменить состояние объекта (команды), либо вернуть результат (запрос), но не то и другое. Таким образом вы сможете избежать побочных эффектов, улучшить читаемость и обеспечить обратимость команд. Например, в банковском приложении метод, переводящий деньги с одного счета на другой, не должен также возвращать баланс счетов, поскольку это нарушит CQS.
Когда использовать:
Сложные домены: Когда система имеет сложную бизнес-логику, и необходимо разделить ответственность для упрощения и оптимизации.
Высокая нагрузка: Когда необходимо масштабировать чтение и запись данных независимо друг от друга.
Разделение ответственности: Когда требуется четкое разделение обязанностей и разные требования к чтению и записи данных.
CQRS - разделение ответственности за выполнение команд и запросов, шаблон проектирования
Расширяет CQS за счет разделения моделей записи и чтения в системе. Это означает, что вы можете использовать разные источники данных, структуры и логику для обработки команд и запросов в зависимости от ваших требований. Например, в приложении для ведения блога вы можете использовать реляционную базу данных для хранения сообщений и комментариев (модель записи), а также поисковую систему для их индексирования и извлечения (модель чтения).
Когда использовать:
Используется для масштабируемых и сложных приложений с высокими требованиями к производительности и разделению ответственности. Когда каждому сервису соответствует своя база данных и необходимо обрабатывать запросы и свести все данный воедино
- Масштабируемость
- Повышение отказоустойчивости
- Повышение показателей доступности
- Не оказывают влияние на другие части приложения
- Гибкость разработки
- Легкость в обслуживании
- Использование различных технологий
- Улучшение производительности разработки
- Упрощение развертывания и обновления
- Сложность разработки и поддержки (тестирование, поддержка, развёртывание)
- Оверхед взаимодействия
- Управление и согласованность данных
- Трудности в тестировании межсервисного взаимодействия
- Мониторинг и логирование
- Оркестрация и управление инфраструктурой
- Сетевые и безопасность
- Дублирование кода и зависимостей