Clean Architecture (чистая архитектура, все для проекта любого размера, принципы, мышление)

Telegram post: Как создать чистую архитектуру и написать чистый код? Какие есть паттерны? Как их применять? Почему все их понимают по-разному? Можно ли их представить без привязки к конкретному языку? Почему для кого-то они не работают? Uncle Bob нас обманул? Их надо использовать в маленьком проекте, скрипте или огромных энтерпрайз решениях? Как бороться со сложностью в наших проектах и делать так, чтобы затраты на внесение новых изменений были оптимальны с его ростом? Можно ли построить монолит на миллионы строк и остаться в здравом уме? На эти и другие каверзные вопросы мы будем отвечать и рассуждать в этом видео. Будет очень много рисунков с отвязкой от конкретных имплементаций на конкретном языке, где это возможно. Где нет - приведем код. Где-то польем воды, как без этого; а то хейтерам не будет работы :) В целом тут все, что нужно знать, как применять и на какой стадии проекта. Когда их пременение дает профит, а когда сильно мешает и усложняет код. Очень много про decoupling & cohesion, на которых мы построим рассуждения почти на всех уровнях абстракции. Первые главы много и нудно говорят про мышление, которое потом красной нитью абстракций будут пронизаны все остальные главы. Не забудем про SOLID и некоторые другие принципы. Упомянем случаи, когда SOLID приводил к сложноподдерживаемой лапше, а когда делал код красивым и понятным. Где-то кринжанем немного. Все как мы любим)) Не все и не все смогут понять и тем более сразу применить на практике. Многие вещи нужно вырабатывать как навык, постоянно рефлексируя, рефакторя код после каждой доработки. Но, мы стараемся быть лучше и использовать это, если появляется возможность сделать наш код лучше и понятней для других людей; код, в который легко и приятно вносить новые изменения. Надеюсь, каждый найдет что-то полезное для себя. Значит, делал не зря. П.С. Любые совпадения с реальностью случайны, никакие темы, кроме разработки не затронуты ни явно, ни косвенно. Telegram post: Telegram: Leetcode: GitHub: Gists: Timecodes 0:00 Intro 32:50 Black and White Thinking 45:55 Modeling & Abstraction 1:07:49 Single Responsibility Principle 1:38:52 Open-Closed Principle 1:58:26 Liskov Substitution Principle 2:18:32 Interface Segregation Principle 2:35:40 Dependency Inversion Principle 3:08:03 DRY 3:20:39 Naming 3:46:57 One Line One Statement 3:55:30 Function’s Size 3:59:20 Loops 4:04:40 Classes 4:09:22 Low Coupling & High Cohesion 4:46:26 Technical Debt 4:52:09 Cyclic Dependency 5:00:37 Gateway (Facade, Orchestrator) 5:11:54 Function Composition 5:18:10 Pure Functions 5:56:26 Idempotent Functions 6:03:20 State & Stateful & Stateless 7:07:28 IO & Functional Core & Imperative Shell 7:39:32 Input Validation 7:47:24 Dependencies Are Bad 8:04:38 Dependency Inversion 8:19:26 Clean Architecture 8:31:38 Hexagonal Architecture 8:56:55 Clean Architecture. Example. Smoothly Increase Complexity 9:13:00 Clean Architecture. Using Functions 9:14:57 Clean Architecture. Using Closure 9:17:13 Clean Architecture. Using Class 9:22:53 Clean Architecture. Using Global Setup 9:28:16 Big Ball Of Mud 9:35:35 Distributed Monolith With Microservices 9:40:41 Monolith 9:47:42 Monolith. Martin Fowler 9:48:52 Monolith. KISS & Make It Work! 9:52:16 Monolith. Refactor. Decoupling. Modules. 9:56:19 Monolith. Ultimate Decoupling. Broker (Sync) 9:59:10 Monolith. Ultimate Decoupling. Broker (Async) 10:01:07 Modular Monolith 10:03:32 Modular Monolith. High Coupling & Low Cohesion 10:04:44 Modular Monolith. Modularization & Refactoring 10:05:13 Modular Monolith. One Database And Direct Function Calls 10:06:37 Modular Monolith. Extract Modules to Microservices 10:08:11 Modular Monolith. Complexity Of Wrong Architecture 10:10:45 Modular Monolith. Complexity Of Wrong Decomposition 10:12:17 Modular Monolith. Scaling Of Monolith 10:13:35 Modular Monolith. Advantages Of Modules 10:15:42 Modular Monolith. Anti-Corruption Layer 10:18:10 Modular Monolith. One Module One Database 10:19:17 Modular Monolith. One Module One Schema 10:20:03 Modular Monolith. Disaster Of Using The Same Tables By Modules 10:23:44 Modular Monolith. Module Boundaries and APIs 10:26:52 Modular Monolith. Communicate With Broker 10:30:49 Data Transfer Objects (DTOs) 10:46:12 In-Memory Broker (Sync) 10:47:44 In-Memory Broker (Async) 10:49:43 Prototyping 10:55:34 Development Cycle 11:07:22 Just Enough Architecture 11:10:32 Architecture Complexity 11:19:51 Black Box #programming #python #Go #cpp #problemsolving #leetcode #interview #job #algorithms #cleancode #clean_code #cleanarchitecture #clean_architecture #solid #solid_principles