Как стать автором
Обновить
110.78

Проектирование и рефакторинг *

Реорганизация кода

Сначала показывать
Порог рейтинга

Дели код на слои - первый принцип. Полный список принципов здесь

Я еще не знаю задачу, но уже знаю, что в коде будет 3 слоя: приложение, инфраструктура, контроллеры. Отдельно конфигурация.

Этого достаточно, ведь у меня даже нет задачи. Я начну думать о моделях, адаптерах, объекта‑значениях, когда приступлю обдумыванию бизнес логики и реализации.

Слой приложения «главный». Он устанавливает правила и требования к интерфейсам других слоев. Он никому ничего не должен. Он не знает, как устроены другие слои, и что внутри, потому что он главный. Слой приложения не может требовать от других слоев навыков работы с закрытыми данными. Он не может передать объект с приватными свойствами в другой слой и хотеть, чтобы эти свойства были обработаны.

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

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

— как модель, которые хранят состояние пока запрос обрабатывается;

— сервис без состояния

— функция с валидации целостности

Контроллеры — это все, что касается ввода и вывода.

Этот слой обязан знать, что нужно слою приложения, обязан это предоставить в нужном формате. Он не может ничего требовать от слоя приложения, обязан работать с тем, что отдал слой приложения.

На фронте в этот слой попадает всё, что касается взаимодействия с пользователем и обработки событий:

— шаблоны, стили, функции, которые готовят данные для отображения и обрабатывают ввод пользователя

— обработчики событий

— обработчики роутов, потому что роутинг — это интерфейс ввода данных.

— слушатели сокет соединений

На бэке это код, который принимает входящие запросы и отдает ответ, фоновые контроллеры:

— контроллеры gRPC, HTTP,

— слушатели очередей,

— конструкторы ответа, мапперы данных в нужный формат и т. п.

— описание протоколов.

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

Инфраструктура

— обязана работать с тем, что отдает слой приложения

— обязана вернуть данные в формате, который требует слой приложения.

Здесь лежат:

— клиенты к хранилищам, другим сервисам, кэшам, очередям и т. п.

— конструкторы запросов к БД, очередям или другим сервисам

— мапперы данных слоя приложения в нужный формат и обратно

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

Это может быть конфигурация di‑контейнера, место ручного создания компонен. Конфигурация может присутствовать как дополнительные нотации в UI компонентах. Фреймворки и языки имеют разные методы конфигурирования, поэтому конфигурация не является слоем или может быть не явной.

Слой приложения может отсутствовать. Тогда контроллеры и инфраструктура взаимодействуют напрямую. Чтобы сохранить порядок, нужно определить — кто главный. Главным лучше делать того, кто более стабилен.

На фронте слой контроллеров может часто меняться, контракт с бэком более стабилен — инфраструктура главная.

На бэке формат хранения может измениться после MVP, а контракт описан и стабилен — слой контроллеров главный.

Слои зависят друг от друга. Правила организации кода и внедрения зависимостей будут в отдельном посте.

Теги:
+6
Комментарии0

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

Кто-то решит, что они вредные. Подумайте, прежде чем применять. Кому-то материал покажется очень простым, почти очевидным. Мой опыт показывает, что даже "бывалые" наводят бардак, хотя все всё понимают.

Принципы сформированы на основе практического применения информации из книг:

В оригиналах некоторые вещи трактуются объемно и широко.

Я про конкретику, практику и про код, поэтому сознательно упростил или выбросил часть информации. Она мешает и запутывает не только новичков, но и опытных разработчиков. Поэтому это не классический DDD или чистая архитектура. Скорее это смешение и личный опыт. Попытаюсь выдавать информацию без "воды".

Погнали:

  1. Дели код на слои

Теги:
+1
Комментарии0

Полезные расширения для vsCode | просмотр JSON в виде дерева | Json Tree editor

Всем привет, этим постом начинаю серию постов с полезными плагинами для vsCode

🚀 Наименование: Json Tree editor

✍️Описание: расширение VSCode для визуализации данных JSON в виде дерева, с возможность выбора, перемещения и сортировки.

🔗 Ссылка на плагин: https://marketplace.visualstudio.com/items?itemName=GregChamblin.vscode-json-editor

Extension id: GregChamblin.vscode-json-editor

➕Плюсы:

  • Можно работать с большими файлами json

  • Есть отдельная кнопка на панели задач

  • При перетаскивании в дереве элементов, сам json также изменяется онлайн

➖Минусы:

  • Не выявлено

🚀Делитесь своими плагинами в комментариях.

#vsCode #JSON

Подписывайтесь на меня в телеграмм, там ещё много интересных плагинов @sa_chulan

Теги:
Всего голосов 2: ↑1 и ↓10
Комментарии0

Современный Spring Boot, это пожалуй лучшее, что есть в экосистеме Java на сегодняшний момент. Особенно если речь идет о Spring модулите.

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

На практике это обычно означает:

Одна БД;

Для каждого модуля своя схема;

Один Git репо;

Каждый модуль можно собирать и тестировать отдельно независимо друг от друга;

Для миграции используется liquibase или flyaway;

Обычно Gradle лучше подходит под модулит;

Деплой одной поставкой/релизом;

Некоторые модули взаимодействуют друг с другом с помощью REST API, а некоторые используют брокер сообщений;

Все это работает в одном неймспейсе Kubernetes если он выбран в качестве целевой платформы;

          +-----------------------------+
          |       Object Storage         |
          |   (e.g., AWS S3, MinIO)      |
          +-----------------------------+
                        |
                        v
+-----------------------------------------------------------+
|                  Kubernetes Namespace                     |
|                                                           |
|  +-----------------------------------------------------+  |
|  |                   API Gateway                       |  |
|  |           (Spring Cloud Gateway)                    |  |
|  +-----------------------------------------------------+  |
|                 ^        ^        ^        ^              |
|                 |        |        |        |              |
|  +----------------+     +----------------+     +-------+  |
|  | Microservice 1 |<--->| Microservice 2 |<--->|  ...  |  |
|  | (REST & Kafka) |     | (Kafka Only)  |      +-------+  |
|  +----------------+     +----------------+                |
|                                                           |
|  +----------------+     +----------------+                |
|  | Microservice 3 |<--->| Microservice 4 |                |
|  | (REST Only)    |     | (Kafka Only)   |                |
|  +----------------+     +----------------+                |
|                                                           |
|  +----------------+     +----------------+                |
|  | Microservice 5 |<--->| Microservice 6 |                |
|  | (Kafka Only)   |     | (REST & Kafka) |                |
|  +----------------+     +----------------+                |
|                                                           |
|  +----------------+     +----------------+                |
|  | Microservice 7 |<--->| Microservice 8 |                |
|  | (REST Only)    |     | (Kafka Only)   |                |
|  +----------------+     +----------------+                |
|                 ^        ^        ^        ^              |
|                 |        |        |        |              |
|  +-----------------------------------------------------+  |
|  |                     Kafka Cluster                    | |
|  |   (Apache Kafka / Event Bus for Async Communication) | |
|  +-----------------------------------------------------+  |
|                                                           |
|  +-----------------------------------------------------+  |
|  |              PostgreSQL HA Database                  | |
|  |   (Primary + Standby Nodes for Data Persistence)     | |
|  +-----------------------------------------------------+  |
|                                                           |
+-----------------------------------------------------------+
Теги:
Рейтинг0
Комментарии2

Выводим Ситника на чистую воду

Топ перлов:

  • Sync-engine избавляет от однотипного кода по загрузке данных .. он заставляет вас проверять isLoading === true и рисовать крутилку.

  • Во всех sync-engine используются нормальные стейт менеджеры .. например, nanostore (см. видео с разбором этой библиотеки).

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

  • CRDT - это просто лог операций (лог операций - это CmRDT и OT, CvRDT даже близко не лог).

  • Работать с IndexedDB через скомпилированный под WASM SQLite быстрее, чем напрямую работать с IndexedDB (разве что, если руки заточены под обнимашки).

Упомянутые ссылки:

Копилка благодарностей

Теги:
Всего голосов 4: ↑1 и ↓3-2
Комментарии1

VK (видео)

📦 API for Any(thing) 2

☝️Возможно ли создать интерфейс для получения любого объекта одинаковым способом? 

Библиотека работает на продакшене в приложениях:
Энергия
NFC Tool
КубГТУ

Во второй части доклада практическая реализация 💡

Хабр
Medium
GitHub

El-Machine.com Apps 🤖

Теория:
Часть 1

Теги:
Рейтинг0
Комментарии0

YouTube (видео)

📦 API for Any(thing) 

☝️Возможно ли создать интерфейс для получения любого объекта одинаковым способом? 

Продолжаю развивать свою идею архитектуры для 100% инкасуляции, разбития на модули и тестирования всего слоя Model

Хабр
Medium
GitHub

Первая часть доклада теоретическая. В поисках API для любого (Any) объекта

Во второй части доклада практическая реализация 💡

Поделитесь мыслями:
Что думаете про декларативны подход? Описываю результат и получаю нужный объект

Часть 2

Теги:
Рейтинг0
Комментарии0

Луковая архитектура, и как не заплакать в процессе погружения. Запись митапа

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

На внутреннем митапе рассказали, как устроена луковая архитектура, границах применимости и о том, как с пользой начать использовать её в разработке. Затронули теорию и практику: рассмотрели специфику луковой архитектуры на примере конкретного pet-проекта. 

Коснулись CQS-CQRS дизайн-паттерна, рассмотрели пайплайн MediatR, реализацию валидаций с FluentValidation, маппинг через AutoMapper, и как организовать сущности доменного слоя. 

Остановились на первых двух слоях — Domain.Core и Application. Об устройстве других слоев (Infrastructure и Web API) поговорим на будущих митапах.

Посмотреть запись митапа можно на YouTube или RUTUBE.

P.S. Это запись внутреннего митапа ИТ-команды Сравни — публикуем эпизоды без NDA, но (надеемся) с пользой для внешнего сообщества.

***

Узнавать о выходе наших новых материалов (митапов, лекций, статей), помимо Хабра, можно в тг-канале инженерного сообщества Сравни

Теги:
Всего голосов 10: ↑10 и ↓0+12
Комментарии0

Всем привет!

Расскажу про один поучительный факап из моей практики.

Более 10 лет назад. Стартап. Я на тот момент и СТО, и разработчик в одном лице. Есть задача, в целом понятная. Декомопозирую на микросервисы и подзадачи, начинаю пилить. Дохожу до XML binding - преобразования XML в объекты. Тогда API в основном были XML. Решил погуглить - что есть на рынке. Кроме известного многим JAXB нахожу JiXB. Не известный тогда, тихо умерший сейчас. Читаю описание и нахожу бенчмарк, показывающий что он ... скажем в 1.5 раза быстрее JAXB. Думаю - о, круто, надо брать. Начинаю прикручивать к Spring. Наталкиваюсь на кучу подводных камней - это не работает, документации мало, ошибки не информативные и не гуглятся. В общем убил неделю на прикручивание к проекту одной библиотеки. В итоге все заработало, конечно. А проект не был доведен до работающего состояния и так и не взлетел.

Итоги. До сих пор стыдно за такое решение по следующим причинам:

  1. речь про стартап, т.е. нужно быстро создать работающий прототип, а не исследовать новые технологии

  2. преждевременная оптимизация - данных по требуемому RPS и доступному железу на тот момент у меня не было. Нагрузочное тестирование не проводилось. Стал бы JAXB узким местом - не факт

  3. использовать в промышленной разработке не доказавшие свою зрелость библиотеки - это риск. Очень важны сообщество и работающие без бубна связки, например, Spring+JAXB. А риск должен быть оправдан, а еще должен быть план отката. Не взлетело, сыро - откатываемся на надежный вариант

Теги:
Всего голосов 8: ↑8 и ↓0+12
Комментарии0

Всем привет!

Вопрос - где применяется подход DDD?
Аналитика, разработка, тестирование. Конечно архитектура АС, с нее все начинается.
Но это еще не все.
Есть такой класс систем как Data Warehouse (DWH) или аналитическое хранилище данных. В это хранилище попадают данные из всех бизнес-сервисов компании для дальнейшего анализа. Т.об. мы разделяем оперативную БД и аналитическую, снимая лишнюю нагрузку с оперативной БД. Особенность Data Warehouse - технологии обработки и хранения данных отличаются от используемых в системах оперативной обработки данных. Hadoop, Greenplum, ClickHouse... А значит нужны специалисты, которые подготовят хранилище под ваши данные и настроят синхронизацию с оперативной БД. Но эти специалисты не знают ваш домен, в отличие от команды. Плюс они часто становятся "бутылочным горлышком". Плюс структура данных постоянно меняется...
Что делать?
Data Warehouse специалисты готовят инфраструктуру, а за подготовку и синхронизацию данных, актуальность их структуры и способ предоставления этих данных потребителям отвечает бизнес команда. Это же ее bounded context. Подход называется Data Mesh. Вот неплохая статья на эту тему.
P.S. На самом деле DevOps в своем идеальном виде о том же - DevOps инженеры готовят инфраструктуру, а за сборку и деплой отвечает команда.

Теги:
Всего голосов 2: ↑2 и ↓0+6
Комментарии0

Всем привет!

Поговорим снова о микросервисах. Я уже писал, почему не стоит делать слишком мелкие микросервисы https://t.me/javaKotlinDevOps/305 (блог в телеге я стал вести сильно раньше, чем на Хабре)
Но встает закономерный вопрос - "сколько вешать в граммах", в смысле - а какого размера должны быть микросервисы?
Обозначим нижний и верхний предел, а для этого придется вспомнить DDD.

Для начала рассмотрим понятие ограниченного контекста (bounded context). Это связанный набор сущностей из реального мира, для наименования которых используется "единый язык" (ubiquitous language) - непротиворечивый набор терминов. Эти сущности описываются в аналитике, тест-кейсах и превращаются в классы в нашем сервисе и в таблицы в БД. Контекстом как правило занимается одна команда - так проще всего поддерживать "единый язык". И за микросервис тоже должна отвечать одна команда. Т.е. ограниченный контекст - это отличный кандидат на микросервис. Но при этом у одной команды может быть несколько микросервисов. И контекст может быть достаточно большим. Т.е. у нас есть верхняя граница микросервиса.

Теперь рассмотрим понятие агрегата - группу сущностей, имеющую уникальный идентификатор, изменение которой производится атомарно. Т.е. агрегат - граница транзакции в БД. А т.к. возможность делегировать управление транзакцией СУБД - это очень крутая штука, то разделять агрегат между разными БД не стоит. При этом один микросервис = одна БД. Поэтому агрегат - нижняя граница микросервиса.

Теги:
Всего голосов 3: ↑1 и ↓2+1
Комментарии0

Всем привет!

Недавно посмотрел интересное видео про управление техдолгом https://youtu.be/pvZDcytPU3w

На самом деле видео не про управление техдолгом в целом. Там нет архитектурного техдолга, технологического. Оно про техдолг, возникающий при реализации конкретной фичи - когда появляется TODO в коде.

Речь идет о извечной проблеме разработчика - "сделать все идеально". Но идеально может потребовать дни или даже недели. А у нас Agile, спринты в 2 недели, бизнес ждет свою фичу.
Что предлагается:

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

  2. если при реализации выясняется, что фичу невозможно сделать в запланированные сроки, а их можно прикинуть исходя из длины спринта, числа задач и их оценки - нужно сделать часть фичи, допускающую продвижение дальше команды. Опять же - декомпозировать сложно, но итеративно это получается лучше.

  3. расставить по коду подробные TODO, рассказать команде что сделано, а что нет и почему, и влить доработку. Т.об. мы гарантировано получаем большую прозрачность. А если правильно удалось определить, что блокер для команды - еще и лучший Lead Time.

  4. далее некий робот сканирует код, находит TODO и делает из них таски в вашем трекере

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

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

    Итого - идея мне нравится!

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0

Всем привет!

TDD конечно крутая штука в плане правильного проектирования сервиса. Правильное проектирование - имеется в виду получить публичное Java API, удобное для использования, если не с первого раза, то с меньшим количеством итераций.

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


Что там может быть:

  • входные данные -> выходные данные

  • обработка возможных исключений

  • повторный запуск: идемпотентность, докат или ошибка

  • параллельный запуск

  • поведение при различных значениях настроек

  • поведение при различных настройках кодировки, языка, часового пояса, файловой системы

  • эффекты из-за отсутствия транзакционности (там где ее нет) ...

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

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

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0

Ближайшие события

Всем привет! 

Меня зовут Дмитрий. В ИТ я сравнительно недавно, всего 25 лет, из которых последние 22 в банковском секторе (ЦБ, ВТБ, Банк ДОМ.РФ). И за это время я стал смотреть по-другому на многие привычные вещи. 

Вот недавно я подумал, что русская народная сказка про царевну-лягушку, это не только про неё. Вы помните: "... нелегко с Кощеем сладить: его смерть ☠️ на конце иглы, та игла в яйце 🥚, яйцо в утке 🦆, утка в зайце 🐇, тот заяц сидит в каменном сундуке 🗃️, а сундук стоит на высоком дубу 🌳, и тот дуб Кощей Бессмертный, как свой глаз, бережёт...". 
Будто бы это не и сказка вовсе, а лаконичное описание архитектуры развертывания. Словно «игла» это приложение 🤖, со встроенной killer-feature, при падении которой происходит необратимое последствие - смерть Кощея. Если перевести на бизнесовый - уход ключевого клиента.

А сколько такого в жизни! И Кощей был побеждён лишь потому, что с гео-распределённым решением заморачиваться не стал, или не смог. 🙈
То есть, в переводе на ИТ-шный, намек этой сказки может выглядеть так: хотите чтобы Ваши сервисы жили вечно - не поступайтесь вопросами надежности ИТ архитектуры. 🏛️

Сказка - ложь, да в ней намёк, ИТ директору урок!
Сказка - ложь, да в ней намёк, ИТ директору урок!

А раньше эта сказка мне казалась просто сказкой ... ☀️

Теги:
Всего голосов 4: ↑2 и ↓2+2
Комментарии1

Разбор доклада Артёма Арутюняна про Архитектуру и Реактивное Программирование

Топ перлов:

  • Реактивное программирование - это программирование на событиях.

  • Реактивность нужна между модулями, а внутри - не нужна.

  • По одному лишь графу связей можно понять правильно произведена декомпозиция или нет.

Мета: Копилка благодарностей, Новости, Форум

Теги:
Всего голосов 7: ↑4 и ↓3+1
Комментарии9

Всем привет!

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

  • корпоративные архитекторы, выравнивающие архитектурные шаблоны

  • внутренние платформы, обязательные к использованию внутри компании и реализующие единообразно нефункциональные требования

  • техрадар как способ ограничить технологический стек

  • единые практики найма и онбординга

  • корпоративная модель данных — как антипод принципа DDD, когда существует некая общая для организации единственно верная доменная модель...

Так вот — что мне нравится в парадигме DDD, что она говорит — не надо бороться, надо принять как данность, расслабиться и получать удовольствие от своего ограниченного контекста). Ремарка – речь про применение закона в проектировании ПО.

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0

Всем привет!

Разработка ПО - очень динамичная сфера. Мэйнфреймы, ассемблер, CSV, RDBMS, C, Delphi, Java, REST, MQ, git, DevOps, Docker, k8s, Kafka, noSQL, microservices, reactive programming, DataLake, GitOps, ChatGPT...
Но есть вещи, которые не меняются. 1967 год, сформулирован закон Конвея - Любая организация, которая разрабатывает систему (в широком смысле), вынуждена создавать проекты, структуры которых являются копией структуры связей организации. Причем если верить wiki, а в данном случае IMHO это можно делать, закон был доказан, видимо на исследовании реальных компаний.
Так вот, читаю сейчас одну интересную книгу про внедрение DDD - Domain Driven Development, 2022 года выпуска. В главе про внедрение вижу такой совет - начать с того, что определить бизнесовые поддомены в компании, на основании которых будут строится ограниченные контексты - одна из ключевых сущностей DDD. Как их проще всего определить? Рекомендуется посмотреть на структуру организации. Закон Конвея в DDD)

P.S. Интересно и то, что в 1967 году разработка как отрасль уже достигла уровня, позволяющего формулировать определенные принципы.

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

«Архитектура программного обеспечения» — обновлённый курс Яндекс Практикума

В рамках курса мы фокусируемся на тех 20% архитектурных задач, проблем и инструментов, которые встречаются в 80% случаев на практике. Это позволяет сделать курс достаточно коротким для такой области, но при этом отвечающим главным запросам студентов.

Основное про курс:

  • Много практики: по окончанию курса вы сможете добавить в портфолио 11 проектов.

  • Качественная обратная связь: все работы будут проверять специалисты с опытом создания распределённой и высоконагруженной архитектуры.

  • Диплом о профессиональной переподготовке или сертификат по окончанию обучения.

Вы научитесь:

  • Проектировать и реализовывать микросервисные архитектуры, управлять ими.

  • Применять паттерны масштабируемости, устойчивости и взаимодействия между сервисами.

  • Развёртывать приложения в облачных средах с помощью Kubernetes, Docker и Terraform, управлять ими.

  • Выстраивать стратегии миграции в облако и управлять большими объёмами данных.

  • Применять репликацию, шардинг и обработку данных в реальном времени.

  • Создавать решения для мониторинга с помощью Prometheus и Grafana.

  • Применять лучшие практики в области безопасности, включая управление идентификацией и доступом (IAM).

  • Интегрировать функции безопасности в дизайн и развёртывание приложений.

  • Общаться с бизнесом на одном языке и помогать выбирать оптимальную технологическую стратегию.

Ближайший старт обучения — 27 июня и 25 июля.

Узнать о курсе подробнее и начать учиться бесплатно →

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0

Monolith-first подход

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

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

Главное - чтобы не получилось так
Главное - чтобы не получилось так

В такой ситуации вы начнёте спокойно делить монолит на микросервисы. Выделите связанные контексты, начнёте вынос кода и миграцию баз данных. Это стандартная история IT-мира. У нас был монолит, но мы выросли и мигрировали на микросервисы.

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

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

Больше интересного про жизнь в IT у меня в ТГ

Теги:
Рейтинг0
Комментарии0

Шаблон декомпозиции ModelView Fractal

Каждый ModelView выступает в роли модели/контроллера для ведомых ModelView и в качестве отображения для владеющего ModelView. Часть логики может выноситься как в чистые Model, так и в чистые View, которые являются лишь вырожденными случаями ModelView.

$my_user_list $my_view
	- \Owner ModelView
	users? /$my_user
	kids /
		<= Row*0 $my_user_row
			user <= user*

$my_user_row $my_card
	- \Having ModevView
	user $my_user
		avatar => image
		nickname => message

$my_card $my_view
	- \View not Model
	kids /
		<= Image $my_image
			uri <= image \about:blank
		<= Message $my_text
			text <= message \
	
$my_user $my_model
	- \Model not View
	avatar? \
	nickname? \

✅ Каждый ModelView полностью контролирует внутренние ModelView и ничего не знает про внешние.
✅ Любой ModelView может шариться между разными другими ModelView на любом уровне композиции.
✅ Изменение интерфейса ModelView требует изменения только лишь его владельцев.
✅ Фрактальная структура легко масштабируется на приложения любого размера.

Теги:
Всего голосов 7: ↑4 и ↓3+1
Комментарии0
1