концепції / domain-knowledge
Знання предметної області
Перша з трьох навичок у стартовому відео каналу: архітектуру диктує предметна область, а не патерни (3 речі, що роблять програміста кращим). Його приклад із чатом робить це відчутним: той самий індикатор «користувач друкує» може вимагати long-polling (коментарі під замовленнями), звичайного polling на 100 запитів/с (корпоративний чат на 100 користувачів) або WebSockets — і лише розуміння домену підказує, що саме. Знання домену живить і мотивацію: його друзі із задоволенням будували e-commerce-частини проєкту й повністю втратили мотивацію на модулі логістики — доки не розібралися в бізнесі за ним, і робота знову стала цікавою.
На цьому концепті тримається його центральне архітектурне попередження: якість архітектури залежить від розуміння домену, а на старті проєкту ви майже ніколи не знаєте домен достатньо добре — саме тому нарізання меж мікросервісів у перший же день і є недооціненим вбивцею цієї архітектури (головна проблема мікросервісів), і саме тому він любить принцип, що хороша архітектура відкладає рішення, доки ви не зрозумієте домен краще.
Розібрано у відео
- 3 речі, які роблять програміста кращим
домен диктує архітектуру (приклад з індикатором набору тексту) і живить мотивацію (історія з логістикою)
- Головна проблема мікросервісів, яку часто недооцінюють
у перший день ніколи не знаєш домен достатньо добре, щоб правильно нарізати межі сервісів
Повʼязане
Проєктування програмного забезпечення — домен як головний вхідний параметр проєктування Мікросервіси — архітектура, яку поверхневе розуміння домену карає найсильніше Абстракції — хороші межі — це межі домену Domain-Driven Design, Implementing Domain-Driven Design — книги, які він радить саме для цього