Python мануфактураJavaDesign Patterns для автоматизаторів

Java · Основний курс · 4:00–6:10

Моноліт, модульний моноліт і мікросервіси

У моноліті business logic, email, SMS, persistence та integrations розгортаються як один application. Це не є автоматично погано: добре структурований моноліт простіший у розробці і не платить network latency за кожен внутрішній виклик. Модульний моноліт розділяє functionality всередині одного deployment і може зберігати окремі data boundaries. Мікросервісна архітектура виносить ці частини у незалежні services, але додає HTTP, serialization, handshakes, deployment і distributed failure modes.

Вступ до API-автоматизації →

Java · Advanced: API-автоматизація · 5:00–10:00

Моноліт, мікросервіси і розподіл відповідальності

У моноліті UI, business logic, persistence і integrations можуть постачатися як один application. У microservice architecture users, products і orders можуть жити в окремих services і мати власні data stores. Дрібні services не гарантують простоти: зростають coupling, deployment overhead і складність пошуку failure. Тому test architecture має відображати фактичні service boundaries, а не ідеалізовану діаграму.

Теоретичний вступ до вебсервісів →

Java · Сесії: AMA та PMP · 11:41–15:35

Міграція моноліту в мікросервіси

Під час декомпозиції логіку, яка раніше жила в одному або кількох класах, переносять у різні services. Треба не лише перенести записи, а й зберегти правила зіставлення полів та джерела кожного значення. Показано типовий регресійний ланцюжок: `fullName` випадково мапиться лише з `lastName`; локальний fix додає `name`, але дані все одно не оновлюються, бо справжнім джерелом був інший service. Так само похідний `status` може формуватися з timestamps лише на одному code path і залишитися `null` під час читання.

Міграція бази даних і тестування даних →
Запитати в чаті про «monolith» →