4-тижневий курс про те, як проектувати системи. Нові — щоб не переробляти, старі-щоб розібрати на частини і прискорити розробку.
Навчимо розпилювати моноліти, обгрунтовано вибираючи технології та архітектурні стилі, залишаючи після себе зрозумілу документацію.
Ви спроектуєте архітектуру проекту на основі зібраних вимог. Зробите модель даних, опишете комунікації, визначте субдомени і архітектурні характеристики проекту. Все це буде розвиватися паралельно з новими знаннями з курсу.
Навчимо розпилювати моноліти, обгрунтовано вибираючи технології та архітектурні стилі, залишаючи після себе зрозумілу документацію.
Ви спроектуєте архітектуру проекту на основі зібраних вимог. Зробите модель даних, опишете комунікації, визначте субдомени і архітектурні характеристики проекту. Все це буде розвиватися паралельно з новими знаннями з курсу.
Урок 1. Kitten: розбиваємо систему на елементи, печемо перший млинець
Мета: навчитися виймати вимоги з бізнесу і вибирати елементи системи на основі цих вимог. Дізнатися перші два види зв'язності-за даними і за викликами. Познайомитися з системою, яку будемо розбирати під час курсу.
яку проблему вирішуємо?
Коли ми тільки починаємо проектувати системи, зазвичай немає ні чітких вимог, ні часу на проектування. Після уроку буде зрозуміло, що навіть в таких умовах можна зібрати щось робоче.
Так само в уроці розбиваємо два антипаттерна-розбивання бізнес-логіки за технічними кроками (потрібен приклад) або по сутностях (entity service)
ключові поняття та терміни:
Спроектуємо першу версію системи. Для цього розглянемо дві базові моделі: Event Storming і Модель даних. Завдяки цим моделям, в майбутньому, будемо покращувати систему з кожною новою ітерацією.
Урок 2. House Cat: вибираємо архітектурний стиль на основі стратегічного аналізу бізнесу
Мета: проаналізувати отриману в першому уроці систему і знайти її слабкі місця. Розібратися в явних і не явних видах пов'язаності, зв'язати зв'язаність і складність системи. Подивитися на проект очима бізнесу, що б позбутися від зайвої пов'язаності між елементами. Визначитися, які характеристики важливі для системи, знайти їх значення і вибрати один з базових архітектурних стилів, заснованих на знайдених характеристиках
яку проблему вирішуємо?
Після першої ітерації, виявилося, що не були враховані не явні зв'язки між знайденими елементами, а самі елементи були знайдені без розуміння яку проблему спочатку вирішує бізнес. При цьому, обрана структура з першого уроку виявилася не валідною бо ми не врахували важливі характеристики проекту. Тому, навчимося Шукати характеристики і вибирати архітектурні стилі грунтуючись на отриманих даних
ключові поняття та терміни:
Учень навчиться дивитися на систему як на набір проблем, вирішення яких йому треба спроектувати. Навчиться бачити зв'язаність елементів не тільки явну, але і засновану на бізнесі і характеристиках. Розбереться в тому, які характеристики існують, як їх знайти і як за допомогою характеристик вибрати потрібний архітектурний стиль. Розберемо, чому описувати детальне рішення для розробників не має ніякого сенсу і замість цього, краще описати елементи, комунікації і задати обмеження, в яких повинна працювати система
Урок 3. Tomcat: вибираємо комунікації, брокери і бази даних, документуємо рішення
Мета: визначити цільову аудиторію, для якої ми робимо систему, завдяки цьому зібрати повні вимоги і повний набір характеристик. Ввести зовнішні обмеження, завдяки чому система зміниться. На основі відмінностей в характеристиках ввести концепцію поділу на сервіси. Розібратися як вибирати патерни, бази даних і способи комунікацій. А так само навчитися стандартизовано описувати прийняті рішення
яку проблему вирішуємо?
У реалізованій системі зацікавлений не тільки сферичний бізнес у вигляді ПМ-а, а й різні види користувачів: фінвідділ, зовнішні інвестори, відділи розробки та інші. Для того, що б отримане рішення задовольняло всіх зацікавлених — необхідно знайти ці особи. При цьому, важливо зрозуміти, чий інтерес важливіше, що б робота над проектом не перетворилася в хаос.
Крім характеристик, існують зовнішні обмеження, такі як закони, кількість інвестицій, загальний рівень інженерів і так далі. Важливо підлаштовувати рішення під ці обмеження, для цього навчимося шукати і пріоритизувати обмеження.
Крім вибору архітектурних стилів, набір обмежень і характеристик можна застосовувати до вибору інших технічних рішень, наприклад баз даних, способах комунікації, вибору брокера і патернів.
Навчимося не тільки приймати рішення, а й описувати їх так, щоб не втрачати контекст, в якому рішення було прийнято. Це дозволить швидше онбордити нових учасників команди.
ключові поняття та терміни:
Учень навчиться Шукати зацікавлені в системі особи, визначати що з вимог зацікавлених осіб важливо, а що ні. Навчиться Шукати обмеження, які впливають на підсумкове рішення і вибирати потрібні стилі, патерни, бази даних і будь-які інші технічні рішення, грунтуючись на отриманих знаннях. Навчиться описувати процес прийняття рішення так, що б контекст не губився.
Урок 4. Alley Cat: розпилюємо Моноліт
Мета: потрапити в ситуацію, коли вже є готова реалізація проекту, який зробили "як змогли". Після аналізу отриманої системи, привести все в порядок, використовуючи п'ять підходів: додати новий функціонал, як окремий сервіс, об'єднати технічні кроки в загальний сервіс, переписати існуючий сервіс, що б він задовольняв характеристикам, винести сервіс з моноліту і позбутися від ентіті сервісу. Для кожної проблеми обговорити стратегії виведення в експлуатацію і кроки для переписування.
яку проблему вирішуємо?
Навчитися рефакторити розподілені системи: додавати новий функціонал, виносити не підходить за характеристиками, об'єднувати сервіси, переписувати існуючі сервіси і позбавлятися від ентіті сервісів. Так само, обговоримо, як планувати і стежити за процесом еволюції сисиеми
ключові поняття та терміни:
Учень отримає практичний досвід модернізації сервісних архітектур. Отримає один із способів спостереження за процесом роботи над системою, який можна застосовувати не тільки для розпилу сервісів, але і в будь-який інший роботі над системою.
Урок 5. Підсумки та подальші кроки
Мета: підвести загальні підсумки і обговорити необхідні кроки для подальшої роботи. Розібратися, як описувати систему. Спланувати етап розвитку власних навичок після курсу і повторити концепції пройдені в курсі.
яку проблему вирішуємо?
Зібрати всі знання разом. Навчитися описувати архітектуру системи так, що б їй можна було користуватися.
ключові поняття та терміни:
Учень отримає чекліст роботи над системою, подальші кроки по самостійному вивченню і опис прикладів того, як можна описувати архітектуру.
Мета: навчитися виймати вимоги з бізнесу і вибирати елементи системи на основі цих вимог. Дізнатися перші два види зв'язності-за даними і за викликами. Познайомитися з системою, яку будемо розбирати під час курсу.
яку проблему вирішуємо?
Коли ми тільки починаємо проектувати системи, зазвичай немає ні чітких вимог, ні часу на проектування. Після уроку буде зрозуміло, що навіть в таких умовах можна зібрати щось робоче.
Так само в уроці розбиваємо два антипаттерна-розбивання бізнес-логіки за технічними кроками (потрібен приклад) або по сутностях (entity service)
ключові поняття та терміни:
- Робота з вимогами
- Event Storming
- Модель даних
- базове порівняння мікросервісів і монолітів
- система, форма та функція системи
Спроектуємо першу версію системи. Для цього розглянемо дві базові моделі: Event Storming і Модель даних. Завдяки цим моделям, в майбутньому, будемо покращувати систему з кожною новою ітерацією.
Урок 2. House Cat: вибираємо архітектурний стиль на основі стратегічного аналізу бізнесу
Мета: проаналізувати отриману в першому уроці систему і знайти її слабкі місця. Розібратися в явних і не явних видах пов'язаності, зв'язати зв'язаність і складність системи. Подивитися на проект очима бізнесу, що б позбутися від зайвої пов'язаності між елементами. Визначитися, які характеристики важливі для системи, знайти їх значення і вибрати один з базових архітектурних стилів, заснованих на знайдених характеристиках
яку проблему вирішуємо?
Після першої ітерації, виявилося, що не були враховані не явні зв'язки між знайденими елементами, а самі елементи були знайдені без розуміння яку проблему спочатку вирішує бізнес. При цьому, обрана структура з першого уроку виявилася не валідною бо ми не врахували важливі характеристики проекту. Тому, навчимося Шукати характеристики і вибирати архітектурні стилі грунтуючись на отриманих даних
ключові поняття та терміни:
- Strategy DDD, Core/Generic/Supporting subdomain, context mapping
- coupling & cohesion, temporal coupling, local & global complexity
- quality attributes/non functional requirements/architecture characteristics
- пошук характеристик і переклад бізнес термінів в характеристики
- цикли життя систем
- fitness functions
- layered, service-based, microservices architecture styles
- V-model
Учень навчиться дивитися на систему як на набір проблем, вирішення яких йому треба спроектувати. Навчиться бачити зв'язаність елементів не тільки явну, але і засновану на бізнесі і характеристиках. Розбереться в тому, які характеристики існують, як їх знайти і як за допомогою характеристик вибрати потрібний архітектурний стиль. Розберемо, чому описувати детальне рішення для розробників не має ніякого сенсу і замість цього, краще описати елементи, комунікації і задати обмеження, в яких повинна працювати система
Урок 3. Tomcat: вибираємо комунікації, брокери і бази даних, документуємо рішення
Мета: визначити цільову аудиторію, для якої ми робимо систему, завдяки цьому зібрати повні вимоги і повний набір характеристик. Ввести зовнішні обмеження, завдяки чому система зміниться. На основі відмінностей в характеристиках ввести концепцію поділу на сервіси. Розібратися як вибирати патерни, бази даних і способи комунікацій. А так само навчитися стандартизовано описувати прийняті рішення
яку проблему вирішуємо?
У реалізованій системі зацікавлений не тільки сферичний бізнес у вигляді ПМ-а, а й різні види користувачів: фінвідділ, зовнішні інвестори, відділи розробки та інші. Для того, що б отримане рішення задовольняло всіх зацікавлених — необхідно знайти ці особи. При цьому, важливо зрозуміти, чий інтерес важливіше, що б робота над проектом не перетворилася в хаос.
Крім характеристик, існують зовнішні обмеження, такі як закони, кількість інвестицій, загальний рівень інженерів і так далі. Важливо підлаштовувати рішення під ці обмеження, для цього навчимося шукати і пріоритизувати обмеження.
Крім вибору архітектурних стилів, набір обмежень і характеристик можна застосовувати до вибору інших технічних рішень, наприклад баз даних, способах комунікації, вибору брокера і патернів.
Навчимося не тільки приймати рішення, а й описувати їх так, щоб не втрачати контекст, в якому рішення було прийнято. Це дозволить швидше онбордити нових учасників команди.
ключові поняття та терміни:
- stakeholders, stakeholders requirements
- обмеження системи
- microkernel, pipeline, event-driven architecture styles
- вибір виду БД в залежності від характеристик
- вибір виду брокера в залежності від характеристик
- вибір патернів в залежності від характеристик
- ADR
Учень навчиться Шукати зацікавлені в системі особи, визначати що з вимог зацікавлених осіб важливо, а що ні. Навчиться Шукати обмеження, які впливають на підсумкове рішення і вибирати потрібні стилі, патерни, бази даних і будь-які інші технічні рішення, грунтуючись на отриманих знаннях. Навчиться описувати процес прийняття рішення так, що б контекст не губився.
Урок 4. Alley Cat: розпилюємо Моноліт
Мета: потрапити в ситуацію, коли вже є готова реалізація проекту, який зробили "як змогли". Після аналізу отриманої системи, привести все в порядок, використовуючи п'ять підходів: додати новий функціонал, як окремий сервіс, об'єднати технічні кроки в загальний сервіс, переписати існуючий сервіс, що б він задовольняв характеристикам, винести сервіс з моноліту і позбутися від ентіті сервісу. Для кожної проблеми обговорити стратегії виведення в експлуатацію і кроки для переписування.
яку проблему вирішуємо?
Навчитися рефакторити розподілені системи: додавати новий функціонал, виносити не підходить за характеристиками, об'єднувати сервіси, переписувати існуючі сервіси і позбавлятися від ентіті сервісів. Так само, обговоримо, як планувати і стежити за процесом еволюції сисиеми
ключові поняття та терміни:
- Entity services
- Strangler Fig Application
- поки не можу написати всі патерни, там їх багато. Якщо прямо терміново-можу зібрати
Учень отримає практичний досвід модернізації сервісних архітектур. Отримає один із способів спостереження за процесом роботи над системою, який можна застосовувати не тільки для розпилу сервісів, але і в будь-який інший роботі над системою.
Урок 5. Підсумки та подальші кроки
Мета: підвести загальні підсумки і обговорити необхідні кроки для подальшої роботи. Розібратися, як описувати систему. Спланувати етап розвитку власних навичок після курсу і повторити концепції пройдені в курсі.
яку проблему вирішуємо?
Зібрати всі знання разом. Навчитися описувати архітектуру системи так, що б їй можна було користуватися.
ключові поняття та терміни:
- все, що в курсі було
- 4+1, C4, arc42, iso42010
Учень отримає чекліст роботи над системою, подальші кроки по самостійному вивченню і опис прикладів того, як можна описувати архітектуру.
https://privatelink.de/?https://education.borshev.com/system-analysis