Другие статьи из серии:
1. Почему MVx архитектуры всегда получаются плохо
2. Как поправить 3 проблемы MVx архитектур
3. Кроссплатформенная архитектура ядра приложения. Простая. Линейная. Масштабируемая
4. Т-функция: подключаем логику к UI как к БД

Описание проблемы

Задача

Я — андроид разработчик. Обычно ко мне приходят с фразой вроде “вот мы тут придумали фичу, сделаешь?” и с макетом дизайна, вроде такого.

Я смотрю на это всё и вижу: вот экраны, эти данные на них — статические, а вот эти динамические, значит их надо откуда-то взять; вот тут интерактивные компоненты: при взаимодействии с ними надо что-то сделать. Иногда просто открыть другой экран или виджет, иногда выполнить логику. Исходя из этого я проектирую то, как будет выглядеть логика фичи. Описываю ее в компонентах архитектуры, разбиваю на задачи, узнаю где и как взаимодействовать с сервером, и прочее.

Скрытые кейсы

Но потом я обнаруживаю, что далеко не все переходы такие простые, как нарисовано на дизайне, например, как в случае с авторизацией. Не все явно присутствуют, как, например, переходы назад. А в некоторых случаях не хватает всевозможных экранов ожидания, экранов “пустых” состояний и экранов ошибок.

Знакомо?

Несмотря на активно развивающийся SaaS‑сегмент рынка и кажущееся стремление компаний использовать облачные ресурсы, отдельные направления IT‑продуктов на рынке продолжают оставаться востребованными крупным бизнесом в виде дистрибуций, разворачиваемых в собственных дата‑центрах (англ. on‑premises) и под собственным контролем.

Программные решения, адаптированные к такому способу поставки, имеют ряд особенностей архитектурного характера, которые влияют на тиражируемость в целом, и должны учитываться на этапе первичного проектирования: топология развёртывания, сайзинг, модульность, интеграции и возможности кастомизации, а также ограничения, накладываемые на прикладное ПО.

В статье рассматриваются некоторые категории варьируемых архитектурно‑значимых нефункциональных требований, ценность которых неочевидна для конечного функционального заказчика, но неоспорима для удовлетворения бюрократического аппарата (IT, ИБ), и даются рекомендации по управлению ими с помощью гибких архитектурных принципов.

Я сейчас занимаюсь разработкой своего pet-проекта: LMS на базе TG, и подошел к стадии набрасывания первых модели: курсы, лекции и их контент. Всё это вывел для дебага.

Но давайте вернёмся к теме. Раз я занялся моделью предметной области, есть один неочевидный момент, который многие упускают на старте проекта: когда проект только начинается, мало кто задумывается, как в будущем мы будем анализировать данные. Но уверяю вас, желание анализировать данные у вас обязательно появится, причём захочется анализировать больше, чем то, что изначально доступно.

Когда люди впервые сталкиваются с аналитикой, они думают: "Надо добавить событийную аналитику и логировать каждое действие." Но у такого подхода есть два основных минуса...

Привет, Хабр! Меня зовут Алексей Топчий, я уже более 20 лет работаю в IT. Прошёл все уровни: бэкенд, фронтенд, фулстек со множеством языков и технологий. В СберТехе занимался Единой фронтальной системой, в Яндексе участвовал в стартапе, связанном с FMCG. Сейчас занимаюсь сервисом ценообразования в сети магазинов «Пятёрочка» (X5 Group). 

В этой статье я приоткрываю тайну бэк-офиса современного магазина и делюсь опытом, как мы развиваем программный комплекс, что интересного при этом происходит, с какими проблемами сталкиваемся и как их решаем. Статья будет полезна архитекторам, техническим менеджерам и всем, кто интересуется преобразованием корпоративных IT-ландшафтов.

В предыдущей статье мы обсудили стратегические паттерны, а теперь давайте углубимся в тактические. Важно помнить: в DDD тактика без стратегии теряет смысл! Если вы не знаете, как правильно разделить систему, отдел или предприятие на контексты и поддомены, ваши усилия, направленные на тактические паттерны, вряд ли принесут плоды. Стратегическое мышление в сочетании с тактическими подходами поможет создать эффективную и гибкую архитектуру, способную справляться с изменениями и требованиями бизнеса.

В этой статье вы найдёте пошаговую инструкцию по тестированию открытого GraphQL API через Postman.

Статья постоена по принципу: сначала практика -> потом теория.

Материал будет полезен системным аналитикам, разработчикам и тестировщикам, которые хотят разобраться в структуре запросов и ответов, понять ключевые принципы работы с GraphQL, подходы к его проектированию, а также научиться интегрироваться с сервисами, предоставляющими GraphQL интерфейс для взаимодействия.

Вы когда-нибудь чувствовали себя потерянным в лабиринте чужого кода, задаваясь вопросами: «Почему здесь используется именно эта технология?» или «Зачем был выбран такой подход к архитектуре?»

В этой статье я рассказываю о том, как Architectural Decision Records (ADR) помогают командам фиксировать и сохранять важные архитектурные решения. Узнайте, как ADR превращает разрозненные знания в структурированный ресурс, доступный каждому члену команды, и почему это важно для эффективности и успеха проекта.

Вы познакомитесь с:
- Преимуществами использования ADR в долгосрочных и сложных проектах.
- Практическими шагами по внедрению ADR без лишней бюрократии.
- Реальным опытом и советами по преодолению возможных препятствий.

Бонусом: шаблон и пример документа в конце статьи.

В разработке ПО важно обеспечивать чистоту и качество кода, чтобы проект оставался легко поддерживаемым.

Однако в ежедневной работе разработчики часто сталкиваются с необходимостью быстро решить задачу, и тогда они начинают оставлять в коде комментарии типа TODO или FIXME для последующего улучшения.

Спустя какое-то время проект оказывается перегружен невыполненными задачами. Подобные комментарии накапливаются и превращаются в невидимый технический долг, который может негативно сказаться на проекте.

Этот список вряд ли является сборником моих собственных оригинальных мыслей. Он начинался как способ представить ценности и принципы Agile Manifesto более понятным и современным способом, хотя я и добавил в него несколько мыслей от себя. Он представляет собой снимок моего образа мышления в определенный момент времени, а не набор неопровержимых истин.

Привет, Хабр!

Сегодня мы рассмотрим одну из тем, которая, как ни странно, остаётся недооценённой — JSON Schema. Если ты аналитик (или хочешь им быть) и в твоей работе часто мелькают JSON-файлы, то наверняка знаешь, как сложно порой бывает держать всё это под контролем. В этой статье мы разберём всё, что тебе нужно знать про JSON Schema.

В этой статье мы обсудим вопросы, с которыми столкнулись разработчики из компании «Наука» при создании Java-приложений и оформлении кода. Эти трудности, «выстраданные» через годы опыта, стали результатом многолетней работы над программным обеспечением для крупных предприятий нефтеперерабатывающей и нефтехимической отрасли.

Наша компания существует уже более 30-ти лет, и на сегодняшний день в ней работает более 100 разработчиков ПО на различных проектах. Одной из основных проблем в нашей компании, и, как мы полагаем, не только в нашей, является большая текучка кадров, в том числе и среди разработчиков. Чтобы упростить и ускорить процесс вхождения вновь пришедших разработчиков в проекты, для программистов, уже работающих в нашей компании, был рекомендован некоторый набор правил по разработке Java-приложений. Также был составлен перечень типовых ошибок при оформлении кода, подробно разобранный на примерах.

Программистам в IT-компаниях, подобных нашей, заказчики платят не за производимый ими код, а за успешную автоматизацию их (заказчиков) бизнес‑процессов. Поэтому материал статьи связан прежде всего с коммерческой разработкой enterprise-систем.

Мы надеемся, что данная статья может быть полезна back-end разработчикам enterprise-систем, работающим в других IT-компаниях.

Ревью - важный этап разработки и одна из самых частых точек взаимодействия разработчиков с кодом и между собой, особенно в распределенных командах. Один разработчик пишет код, другой (ревьюер) - проверяет написанное, а тимлид хочет, чтобы ревью было быстрым и качественным.

Что же можно сделать в каждой из трех ролей, чтобы все остались довольны (и целы)?

"Если ты такой умный, то где твои деньги?"

В настоящей статье рассмотрим вопрос о том, как СОД позволяет повысить маржинальность проектной деятельности. Наибольшие затраты при проектировании идут на оплату труда специалистов. Себестоимость подготовки проектной документации зависит от времени, которое компания затратит на ее подготовку. Для повышения маржинальности следует рассмотреть возможности сокращения времени проектирования без потери качества.

В мире, где архитектура встречает технологию, проектирование становится не просто ремеслом, а философским актом. Каждое здание, каждое сооружение — это нечто большее, чем просто сумма материалов и конструкций. Это отражение нашего времени, наших ценностей и стремлений. И в этом контексте системы автоматизированного проектирования (САПР) представляют собой не просто инструмент, а целую парадигму, меняющую наше восприятие пространства и формы.

Пример создания Full Stack проекта, используя функциональное тестирование как инструмент дизайна(продолжение)

API часть и релиз проекта

Задача этой статьи только одна - попробовать уложить принципы SOLID на понятных «бытовых» примерах, а уже потом посмотреть, как оно может работать на практике - в коде.

Итак, SOLID - это 5 принципов, которые используются при разработке приложений. На каждый принцип по букве:

1. S — Single Responsibility Principle (Принцип единственной ответственности)

Определение: Каждый класс должен выполнять только одну задачу.

Пример из жизни:

Например, мы купили шкаф для одежды. 

Сразу хочу сказать: я не профи в выборе и тем более правильного построения архитектуры умного дома. Я всего лишь обычный программист мобильных игрушек. Вот как надоесть рекламой в игре — это ко мне.

Пару лет назад приобрёл участок, провёл электричество, построил домик. Появилась нужда автоматизировать некоторые моменты и иметь возможность смотреть состояние и управлять автоматизацией удалённо.

В рамках этой статьи я опишу создание двух NestJS-модулей с различным способом конфигурирования: утилитарный модуль и бизнес-модуль со своей базой данных.