Привет!
Крутой доклад оединственно верном функциональном подходе к управлению состоянием.
И львиная доля кода на JSе:)
Настоятельно рекомендую всем, у кого состояние ещё раскидано по всему приложению
#talks@ergonomic_code #functional_architecture@ergonomic_code #js@ergonomic_code
Крутой доклад о
И львиная доля кода на JSе:)
Настоятельно рекомендую всем, у кого состояние ещё раскидано по всему приложению
#talks@ergonomic_code #functional_architecture@ergonomic_code #js@ergonomic_code
YouTube
Solving Problems the Clojure Way - Rafal Dittwald
After overcoming a fear of brackets, the next challenge for would-be Clojurians is less superficial: to stop writing Java (or Javascript, or Haskell...) with Clojure's syntax, and actually start "thinking" in Clojure. It is said that Clojure is a "functional"…
Привет!
Прочитал одну из самых крутых книг по разработке информационных систем в своей жизни - Unit Testing Principles, Practices, and Patterns.
Не дайте ввести себя в заблуждение скромному названию - эта книга представляет собой кладезь мудрости и принципов программирования и проектирования в целом. Плюс в ней представлено лучшее из известных мне на данный момент описание прагматичной (без монад) функциональной архитектуры.
В некоторых деталях я с автором не согласен, но в целом эта книга чуть менее, чем полностью раскрывает два из трёх столпов Эргономичного подхода - тестирование на соответствие требованиям и декларативный стиль.
Вердикт - маст рид вне очереди.
Апдейт статуса поста по диаграмме эффектов - первый драфт с подробным описанием примера построения готов. Но предстоит ещё как минимум несколько итераций ревью и вычитки, плюс у меня буквально сегодня ночью появились идеи изменения нотации, поэтому релиз будет недели через две минимум. Стей тюнед, вобщем:)
#books@ergonomic_code #ergo_testing@ergonomic_code #functional_architecture@ergonomic_code
Прочитал одну из самых крутых книг по разработке информационных систем в своей жизни - Unit Testing Principles, Practices, and Patterns.
Не дайте ввести себя в заблуждение скромному названию - эта книга представляет собой кладезь мудрости и принципов программирования и проектирования в целом. Плюс в ней представлено лучшее из известных мне на данный момент описание прагматичной (без монад) функциональной архитектуры.
В некоторых деталях я с автором не согласен, но в целом эта книга чуть менее, чем полностью раскрывает два из трёх столпов Эргономичного подхода - тестирование на соответствие требованиям и декларативный стиль.
Вердикт - маст рид вне очереди.
Апдейт статуса поста по диаграмме эффектов - первый драфт с подробным описанием примера построения готов. Но предстоит ещё как минимум несколько итераций ревью и вычитки, плюс у меня буквально сегодня ночью появились идеи изменения нотации, поэтому релиз будет недели через две минимум. Стей тюнед, вобщем:)
#books@ergonomic_code #ergo_testing@ergonomic_code #functional_architecture@ergonomic_code
👍7
Привет!
Микропост "Как сделать функциональную архитектуру?"
1) Берём чистую архитектуру (считаем, что это очевидно)
2) Перечитываем книгу и убеждаемся, что у нас:
2.1) Entity - это объект, который включает небольшое количество бизенс-правил (а не полей) (An Entity is an object within our computer system that embodies a small set of critical business rules operating on Critical Business Data)
2.2) Use Case - только лишь управляет потоком данных между сущностей (These use cases orchestrate the flow of data to and from the entities, and direct those entities to use their Critical Business Rules to achieve the goals of the use case)
3) Накладываем на сущности ограничение, что они реализуются чистыми функциями и неизменяемым структурами данных
4) Называем сущности функциональным ядром
5) Всё остальное называем императивной оболочкой.
6) Функциональная архитектура готова
А с учётом того, что анкл Боб сейчас топит за ФП, то это может оказаться не функциональной архитектурой, а идиоматичной чистой по версии анкл Боба...
В качестве вишенки на торе, если требования позволяют, я бы ещё выкинул инверсию зависимости между юз кейсами и инфраструктурой, всё равно самое важное - домен - мы уже изолировали.
#posts@ergonomic_code #functional_architecture@ergonomic_code #ergo_approach@ergonomic_code
Микропост "Как сделать функциональную архитектуру?"
1) Берём чистую архитектуру (считаем, что это очевидно)
2) Перечитываем книгу и убеждаемся, что у нас:
2.1) Entity - это объект, который включает небольшое количество бизенс-правил (а не полей) (An Entity is an object within our computer system that embodies a small set of critical business rules operating on Critical Business Data)
2.2) Use Case - только лишь управляет потоком данных между сущностей (These use cases orchestrate the flow of data to and from the entities, and direct those entities to use their Critical Business Rules to achieve the goals of the use case)
3) Накладываем на сущности ограничение, что они реализуются чистыми функциями и неизменяемым структурами данных
4) Называем сущности функциональным ядром
5) Всё остальное называем императивной оболочкой.
6) Функциональная архитектура готова
А с учётом того, что анкл Боб сейчас топит за ФП, то это может оказаться не функциональной архитектурой, а идиоматичной чистой по версии анкл Боба...
В качестве вишенки на торе, если требования позволяют, я бы ещё выкинул инверсию зависимости между юз кейсами и инфраструктурой, всё равно самое важное - домен - мы уже изолировали.
#posts@ergonomic_code #functional_architecture@ergonomic_code #ergo_approach@ergonomic_code
👍2🤮1
Привет!
Дочитал Code That Fits in Your Head.
И хотя там есть нюансики (использование фейков БД, складирование всего кода в одной директории 🤯🤦♂️), автор топит за outside in tdd и функциональную архитектуру - рекомендую. Особенно молодым разработчиком.
Плюс практически одновременно досмотрел доклад Влашина Moving IO to the edges of your app: Functional Core, Imperative Shell - в целом, наверное, ничего прорывного в докладе нет, но если вы (как и я) ещё не уверены, что знаете на 100% как её применять - можно посмотреть. Там примеры на C# и никаких монад.
#books@ergonomic_code #talks@ergonomic_code #functional_architecture@ergonomic_code
Дочитал Code That Fits in Your Head.
И хотя там есть нюансики (использование фейков БД, складирование всего кода в одной директории 🤯🤦♂️), автор топит за outside in tdd и функциональную архитектуру - рекомендую. Особенно молодым разработчиком.
Плюс практически одновременно досмотрел доклад Влашина Moving IO to the edges of your app: Functional Core, Imperative Shell - в целом, наверное, ничего прорывного в докладе нет, но если вы (как и я) ещё не уверены, что знаете на 100% как её применять - можно посмотреть. Там примеры на C# и никаких монад.
#books@ergonomic_code #talks@ergonomic_code #functional_architecture@ergonomic_code
YouTube
Moving IO to the edges of your app: Functional Core, Imperative Shell - Scott Wlaschin
This talk was recorded at NDC London in London, England. #ndclondon #ndcconferences #developer #softwaredeveloper
Attend the next NDC conference near you:
https://ndcconferences.com
https://ndclondon.com/
Subscribe to our YouTube channel and learn…
Attend the next NDC conference near you:
https://ndcconferences.com
https://ndclondon.com/
Subscribe to our YouTube channel and learn…
❤5👍5
Привет!
Не прошло и месяца и я сделал это!
Представляю вашему вниманию Project Mariotte - минималистичный и подробно задокументированный демопроект Эргономичного подхода на примере сервиса бронирования номеров в отелях.
У меня есть идея ещё пары-тройки проектов, с демонстрацией более развесистой бизнес-логики и более сложными взаимодействиями с инфраструктурой - надеюсь на горизонте пары лет их я тоже сделаю:)
#project_mariotte@ergonomic_code #ergo_approach@ergonomic_code #spring@ergonomic_code #tdd@ergonomic_code #functional_architecture@ergonomic_code #dop@ergonomic_code #immutable_domain_model@ergonomic_code
Не прошло и месяца и я сделал это!
Представляю вашему вниманию Project Mariotte - минималистичный и подробно задокументированный демопроект Эргономичного подхода на примере сервиса бронирования номеров в отелях.
У меня есть идея ещё пары-тройки проектов, с демонстрацией более развесистой бизнес-логики и более сложными взаимодействиями с инфраструктурой - надеюсь на горизонте пары лет их я тоже сделаю:)
#project_mariotte@ergonomic_code #ergo_approach@ergonomic_code #spring@ergonomic_code #tdd@ergonomic_code #functional_architecture@ergonomic_code #dop@ergonomic_code #immutable_domain_model@ergonomic_code
GitHub
GitHub - ergonomic-code/Project-Mariotte: Демонстрационный проект Эргономичного подхода - сервис бронирования номеров в отелях
Демонстрационный проект Эргономичного подхода - сервис бронирования номеров в отелях - ergonomic-code/Project-Mariotte
👍16🔥6
Привет!
Я в Project Mariotte сделал страшное - перешёл на MockMvc.
Изначальная мотивация была в том, чтобы сэкономить секунду на запуске Tomcat.
Потом выяснилось, что инициализация RestAssured занимает ещё секунду, которую тоже можно сэкономить
Но последним аргументом стало то, что со WebTestClient можно переехать на работу через HTTP затри четыре простых шага.
И это навело меня на мысли об эволюции ЭП от сложного к простому за последние 4 года.
В конце 19-ого - начале 20-ого года можно было сказать, что ЭП = модульный монолит + тесты без моков + ДДД + чистая архитектура + railway-oriented programming на монадах.
И на тот момент, это всё (на мой взгляд) были маргинальные идеи, не имеющие широкого распространения.
Но за прошедшие 4 года, они все если не вошли, то сильно приблизились к мейнстриму, на мой взгляд.
А я с ЭП за эти же 4 года то ли ушёл вперёд, то ли откатился назад:
1. К модульному монолиту добавились цитадели, а для самого монолита появилось ограничение, что типовой тест должен отрабатывать не больше чем за 30 секунд
2. В тестировании добавилось разрешение на использование моков для симуляции ошибок инфраструктуры и для дорогой инфраструктуры. И свеженькое разрешение на использование MockMvc, при условии, что код самих клиентв (тест-кейсов) на него не завязан.
3. От ДДД осталась только декомпозиция модели на агрегаты, но по более приземлённой технологии на базе жизненного цикла сущностей и транзакционного анализа; а вместо ограниченных контекстов - декомпозиция на базе эффектов;
4. Чистую архитектуру я заменил на тщательное проектирование интерфейсов;
5. ROP на монадах, наконец, я заменил на Guard clause.
И при этом Эргономичный подход остаётся совместимым со всеми этими идеями там, где это надо:
1. Цитадель оказалась плохой затеей? Затолкать её обратно в монолит - вообще не проблема;
2. Тестов на моках стало слишком много или появилось слишком много багов в обработке ошибок? Поменять моки на стабы - уже сложнее, но тоже вполне решаемая задача;
3. В проекте появилась сложная предметная область и/или эксперт по ней? Перейти на ограниченные контексты и агрегаты на базе инвариантов - без проблем, вся инфраструктура и структура кодовой базы готовы;
4. В проекте появилась необходимость менять инфраструктуру без пересборки/перезапуска? Вытащить интерфейс из существующего класса - дело 5 минут. С реализацией сложнее, но это другой вопрос;
5. В проекте появилась потребность на лету собирать пайплайны? Обернуть имеющиеся вызовы эффективных методов в монады не составит труда.
А прямо сейчас, в моменте, ваш код будет максимально простым, без лишних сложностей и архитектуры.
Изначально Эргономичный подход был глотком свежего воздуха для тех, кто устал от хаоса и багов императивной слоёнки с тестами на моках.
Теперь Эргономичный подход стал глотком свежего воздуха для тех, кто устал от поисков стороны, с которой подойти к ДДД, церемоний чистой архитектуры и сложностей объяснения монад простым смертным.
В общем, покой нам только снится:)
#ergo_approach@ergonomic_code #project_mariotte@ergonomic_code #tdd@ergonomic_code #ergo_testing@ergonomic_code #mocks@ergonomic_code #clean_architecture@ergonomic_code #functional_architecture@ergonomic_code #ddd@ergonomic_code #rop@ergonomic_code
Я в Project Mariotte сделал страшное - перешёл на MockMvc.
Изначальная мотивация была в том, чтобы сэкономить секунду на запуске Tomcat.
Потом выяснилось, что инициализация RestAssured занимает ещё секунду, которую тоже можно сэкономить
Но последним аргументом стало то, что со WebTestClient можно переехать на работу через HTTP за
И это навело меня на мысли об эволюции ЭП от сложного к простому за последние 4 года.
В конце 19-ого - начале 20-ого года можно было сказать, что ЭП = модульный монолит + тесты без моков + ДДД + чистая архитектура + railway-oriented programming на монадах.
И на тот момент, это всё (на мой взгляд) были маргинальные идеи, не имеющие широкого распространения.
Но за прошедшие 4 года, они все если не вошли, то сильно приблизились к мейнстриму, на мой взгляд.
А я с ЭП за эти же 4 года то ли ушёл вперёд, то ли откатился назад:
1. К модульному монолиту добавились цитадели, а для самого монолита появилось ограничение, что типовой тест должен отрабатывать не больше чем за 30 секунд
2. В тестировании добавилось разрешение на использование моков для симуляции ошибок инфраструктуры и для дорогой инфраструктуры. И свеженькое разрешение на использование MockMvc, при условии, что код самих клиентв (тест-кейсов) на него не завязан.
3. От ДДД осталась только декомпозиция модели на агрегаты, но по более приземлённой технологии на базе жизненного цикла сущностей и транзакционного анализа; а вместо ограниченных контекстов - декомпозиция на базе эффектов;
4. Чистую архитектуру я заменил на тщательное проектирование интерфейсов;
5. ROP на монадах, наконец, я заменил на Guard clause.
И при этом Эргономичный подход остаётся совместимым со всеми этими идеями там, где это надо:
1. Цитадель оказалась плохой затеей? Затолкать её обратно в монолит - вообще не проблема;
2. Тестов на моках стало слишком много или появилось слишком много багов в обработке ошибок? Поменять моки на стабы - уже сложнее, но тоже вполне решаемая задача;
3. В проекте появилась сложная предметная область и/или эксперт по ней? Перейти на ограниченные контексты и агрегаты на базе инвариантов - без проблем, вся инфраструктура и структура кодовой базы готовы;
4. В проекте появилась необходимость менять инфраструктуру без пересборки/перезапуска? Вытащить интерфейс из существующего класса - дело 5 минут. С реализацией сложнее, но это другой вопрос;
5. В проекте появилась потребность на лету собирать пайплайны? Обернуть имеющиеся вызовы эффективных методов в монады не составит труда.
А прямо сейчас, в моменте, ваш код будет максимально простым, без лишних сложностей и архитектуры.
Изначально Эргономичный подход был глотком свежего воздуха для тех, кто устал от хаоса и багов императивной слоёнки с тестами на моках.
Теперь Эргономичный подход стал глотком свежего воздуха для тех, кто устал от поисков стороны, с которой подойти к ДДД, церемоний чистой архитектуры и сложностей объяснения монад простым смертным.
В общем, покой нам только снится:)
#ergo_approach@ergonomic_code #project_mariotte@ergonomic_code #tdd@ergonomic_code #ergo_testing@ergonomic_code #mocks@ergonomic_code #clean_architecture@ergonomic_code #functional_architecture@ergonomic_code #ddd@ergonomic_code #rop@ergonomic_code
GitHub
GitHub - ergonomic-code/Project-Mariotte: Демонстрационный проект Эргономичного подхода - сервис бронирования номеров в отелях
Демонстрационный проект Эргономичного подхода - сервис бронирования номеров в отелях - ergonomic-code/Project-Mariotte
👌2
Привет!
По совету подписчика начал читать Grokking Simplicity.
Пока прочитал 200 страниц из 600, но уже не могу удержать в себе восторг.
Это лучшая известная мне книга по функциональному стилю (или скорее data-oriented programming), с лучшим известным мне разбором двух основополагающих принципов проектирования:
1. разделение ввода-вывода и бизнес-логики
2. использование одного уровня абстракции в функции (анкл Бобовскя заметка на эту тему в чистом коде - даже близко не лежала с 1.5 главами об этом в книге).
Настоятельно рекомендую прочитать эту книгу всем, с опытом коммерческой работы от года и до бесконечности.
#books@ergonomic_code #functional_architecture@ergonomic_code #fp@ergonomic_code #js@ergonomic_code
По совету подписчика начал читать Grokking Simplicity.
Пока прочитал 200 страниц из 600, но уже не могу удержать в себе восторг.
Это лучшая известная мне книга по функциональному стилю (или скорее data-oriented programming), с лучшим известным мне разбором двух основополагающих принципов проектирования:
1. разделение ввода-вывода и бизнес-логики
2. использование одного уровня абстракции в функции (анкл Бобовскя заметка на эту тему в чистом коде - даже близко не лежала с 1.5 главами об этом в книге).
Настоятельно рекомендую прочитать эту книгу всем, с опытом коммерческой работы от года и до бесконечности.
#books@ergonomic_code #functional_architecture@ergonomic_code #fp@ergonomic_code #js@ergonomic_code
Manning Publications
Grokking Simplicity - Eric Normand
This practical guide will change the way you approach software design and development. It shows you how to write software that keeps complexity close to its inherent minimum.
👍12
Эргономичный код
Привет! По совету подписчика начал читать Grokking Simplicity. Пока прочитал 200 страниц из 600, но уже не могу удержать в себе восторг. Это лучшая известная мне книга по функциональному стилю (или скорее data-oriented programming), с лучшим известным мне…
Привет!
Дочитал книгу. По традиции, тема разработки бэков поверх РСУБД практически не раскрыта (этому посвящено примерно 10 страниц про луковую архитектуру), но в остальном - чудесная книга, мой новый лидер среди книг по ФП.
И сейчас мой рекомендуемый трек по изучению разработки бэков в функциональном стиле выглядит так:
1. Grokking Simplicity
2. Принципы юнит тестирования
3. Domain Modeling Made Functional
4. Структура и интерпретация компьютерных программ
5. Functional Design: Principles, Patterns, and Practices
6. Structured Design
#books@ergonomic_code #functional_architecture@ergonomic_code #fp@ergonomic_code #js@ergonomic_code
Дочитал книгу. По традиции, тема разработки бэков поверх РСУБД практически не раскрыта (этому посвящено примерно 10 страниц про луковую архитектуру), но в остальном - чудесная книга, мой новый лидер среди книг по ФП.
И сейчас мой рекомендуемый трек по изучению разработки бэков в функциональном стиле выглядит так:
1. Grokking Simplicity
2. Принципы юнит тестирования
3. Domain Modeling Made Functional
4. Структура и интерпретация компьютерных программ
5. Functional Design: Principles, Patterns, and Practices
6. Structured Design
#books@ergonomic_code #functional_architecture@ergonomic_code #fp@ergonomic_code #js@ergonomic_code
Manning Publications
Grokking Simplicity - Eric Normand
This practical guide will change the way you approach software design and development. It shows you how to write software that keeps complexity close to its inherent minimum.
👍10
Привет!
Прочитал Java to Kotlin: A Refactoring Guidebook - мне понравилась.
Её с тем же успехом можно было назвать "Рефакторинг императивного стиля в функциональный" и она хорошо дополняет Grokking Simplicity - на мой вкус менее фундаментальная, но более бакэндерская и со статической типизацией. Хотя, опять же, тема персистанса практически не раскрыта.
И в качестве инструкции по переходу на Котлин она тоже хороша.
Рекомендую, в общем.
Ещё пару находок оттуда:
1. Идея "волокон" (grains) языков программирования. "Вдоль" которых работать проще, чем поперёк - как с деревом. И ФП укладывается вдоль волокон Котлина, но идёт поперёк волокон Джавы. С одной стороны. С другой стороны, монады - не укладываются в волокна Котлина.
2. У Фаулера есть статья про баги вызванные алиасингом
3. Один из соавторов этой книги - также соавтор и Growing Object-Oriented Software Guided by Tests - книги, которую я долгое время считал идеологически вредной. В Java to Kotlin же он пишет, что в GOOS моки не предполагалось использовать в качестве стабов - поставщиков данных через ридонли методы. Возможно, мне стоит перечитать GOOS и поменять своё мнение о ней.
#books@ergonomic_code #functional_architecture@ergonomic_code #kotlin@ergonomic_code #java@ergonomic_code
Прочитал Java to Kotlin: A Refactoring Guidebook - мне понравилась.
Её с тем же успехом можно было назвать "Рефакторинг императивного стиля в функциональный" и она хорошо дополняет Grokking Simplicity - на мой вкус менее фундаментальная, но более бакэндерская и со статической типизацией. Хотя, опять же, тема персистанса практически не раскрыта.
И в качестве инструкции по переходу на Котлин она тоже хороша.
Рекомендую, в общем.
Ещё пару находок оттуда:
1. Идея "волокон" (grains) языков программирования. "Вдоль" которых работать проще, чем поперёк - как с деревом. И ФП укладывается вдоль волокон Котлина, но идёт поперёк волокон Джавы. С одной стороны. С другой стороны, монады - не укладываются в волокна Котлина.
2. У Фаулера есть статья про баги вызванные алиасингом
3. Один из соавторов этой книги - также соавтор и Growing Object-Oriented Software Guided by Tests - книги, которую я долгое время считал идеологически вредной. В Java to Kotlin же он пишет, что в GOOS моки не предполагалось использовать в качестве стабов - поставщиков данных через ридонли методы. Возможно, мне стоит перечитать GOOS и поменять своё мнение о ней.
#books@ergonomic_code #functional_architecture@ergonomic_code #kotlin@ergonomic_code #java@ergonomic_code
Java to Kotlin
Java to Kotlin: A Refactoring Guidebook
Supplementary resources
👍6
Привет!
Тизер из доклада - я кажись нашёл железобетонный аргумент и пример в пользу ФА.
Это графы вызовов методов одной и той же реальной функции реального коммерческого проекта.
Слева - сделано "как обычно".
Справа - по ФА/ЭП.
Правый граф в проде (давно уже).
И это ещё на графах не подсвечена когнитивная сложность - левый при сложности всей структуры в целом, ещё будет иметь и сложность отдельных элементов намного большую - максимальная разница - 4 раза.
И правый граф работает в 300 раз быстрее (я замерял).
Оба графа сделаны на Java 8 + Spring Boot.
Левый граф сделан на Hibernate, правый - Spring JDBC Template, с небольшими вкраплениями Hibernate
Если и после этого люди ещё будут сомневаться нужно ли им ФП/ФА - я умываю руки.
#functional_architecture@ergonomic_code #whyfa@ergonomic_code #whynotjpa@ergonomic_code
Тизер из доклада - я кажись нашёл железобетонный аргумент и пример в пользу ФА.
Это графы вызовов методов одной и той же реальной функции реального коммерческого проекта.
Слева - сделано "как обычно".
Справа - по ФА/ЭП.
Правый граф в проде (давно уже).
И это ещё на графах не подсвечена когнитивная сложность - левый при сложности всей структуры в целом, ещё будет иметь и сложность отдельных элементов намного большую - максимальная разница - 4 раза.
И правый граф работает в 300 раз быстрее (я замерял).
Оба графа сделаны на Java 8 + Spring Boot.
Левый граф сделан на Hibernate, правый - Spring JDBC Template, с небольшими вкраплениями Hibernate
Если и после этого люди ещё будут сомневаться нужно ли им ФП/ФА - я умываю руки.
#functional_architecture@ergonomic_code #whyfa@ergonomic_code #whynotjpa@ergonomic_code
👍10
Привет!
В комментах к прошлому посту "внезапно" (🤦♂️ ) выяснилось что разные люди под "ФП" понимают разное.
Поэтому накатал коротенький микропост о том, что я имею ввиду говоря ФП
#terminology@ergonomic_code #fp@ergonomic_code #functional_architecture@ergonomic_code #oop@ergonomic_code #ergo_approach@ergonomic_code
В комментах к прошлому посту "внезапно" (
Поэтому накатал коротенький микропост о том, что я имею ввиду говоря ФП
#terminology@ergonomic_code #fp@ergonomic_code #functional_architecture@ergonomic_code #oop@ergonomic_code #ergo_approach@ergonomic_code
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🔥3
Привет!
Ну чтош, ютуб решил всё за нас - без подтверждения загрузить видео более чем на 15 минут не даёт и подтвердить акк на мой номер телефона тоже не даёт.
Так что представляю вам свой канал на Рутубе и первый видос на нём - РЕПЕТИЦИЯ доклада "Функциональная архитектура и Spring Data JDBC. 4 года в проде, полёт отличный"
#talks@ergonomic_code #ergo_approach@ergonomic_code #functional_architecture@ergonomic_code #ergo_persistance@ergonomic_code #spring_data_jdbc@ergonomic_code
Ну чтош, ютуб решил всё за нас - без подтверждения загрузить видео более чем на 15 минут не даёт и подтвердить акк на мой номер телефона тоже не даёт.
Так что представляю вам свой канал на Рутубе и первый видос на нём - РЕПЕТИЦИЯ доклада "Функциональная архитектура и Spring Data JDBC. 4 года в проде, полёт отличный"
#talks@ergonomic_code #ergo_approach@ergonomic_code #functional_architecture@ergonomic_code #ergo_persistance@ergonomic_code #spring_data_jdbc@ergonomic_code
RUTUBE
Эргономичный код — полная коллекция видео на RUTUBE
Канал о разработе поддерживаемых бакэндов - модульных монолитов с неизменяемой моделью данных и функциональной архитектурой, написанных в стиле data-oriented programming и покрытых тестами без моков.
https://t.me/ergonomic_code
https://azhidkov.pro
https://t.me/ergonomic_code
https://azhidkov.pro
❤16👍6🤡4
Привет!
Немного размышлений о чистоте модели предметной области по мотивам рассылки On domain model purity от Хорикова.
Он там пишет:
То есть Хориков полагает, что наличие БД влияет на дизайн системы.
И когда-то я думал так же. В частности, qbit был попыткой сделать такую систему хранения, которая позволила бы писать программы так, как будто все данные живут в памяти.
А сейчас я думаю, что с точки зрения дизайна у меня ничего не поменяется.
Я всё равно буду моделировать состояние системы как набор изменяемых Map неизменяемых структур данных (ака Spring Data JDBC Repository).
Возможно, у меня будет меньше специализированных под юз кейсы ДТОшек.
Совершенно точно я начну спокойно ходить по ссылкам между сущностями внутри бизнес-логики (а-ля Datomic Pull API)..
Но совершенно точно не перейду на модель огромного графа изменяемых объектов (которую, судя по всему Хориков считает идеально чистой).
При том у Хорикова в самом примере есть противоречие:
С одной стороны, он пишет:
Но с другой стороны, в примере он использует репоз для того, чтобы обеспечить уникльность емейла студента. И вот куда он засунет поиск студента по емейлу? В
Кажется, единственное разумное место, куда можно эту проверку засунуть - StudentsRepository. Где бы он не хранил свои данные - в памяти или БД.
В общем, функциональная модель не только лучше отражает модель в голове конечного пользователя, но и лучше отражает природу информационных систем.
#functional_architecture@ergonomic_code #ddd@ergonomic_code
Немного размышлений о чистоте модели предметной области по мотивам рассылки On domain model purity от Хорикова.
Он там пишет:
To see how pure your domain model is, you need to imagine how you would design it if you didn’t have to persist any data to the database, and all you had to do is keep that data in the application memory. Then you need to compare this design to what you ended up with in your project. The difference would be the dent in domain model purity
Чтобы увидеть, насколько чиста ваша модель предметной области, вам нужно представить, как бы вы ее спроектировали, если бы вам не нужно было сохранять какие-либо данные в базе данных, а все, что вам нужно было сделать, это сохранить эти данные в памяти приложения. Затем вам нужно сравнить этот дизайн с тем, что в итоге получилось в вашем проекте. Разница между ними и будет дырой в чистоте вашей модели.
То есть Хориков полагает, что наличие БД влияет на дизайн системы.
И когда-то я думал так же. В частности, qbit был попыткой сделать такую систему хранения, которая позволила бы писать программы так, как будто все данные живут в памяти.
А сейчас я думаю, что с точки зрения дизайна у меня ничего не поменяется.
Я всё равно буду моделировать состояние системы как набор изменяемых Map неизменяемых структур данных (ака Spring Data JDBC Repository).
Возможно, у меня будет меньше специализированных под юз кейсы ДТОшек.
Совершенно точно я начну спокойно ходить по ссылкам между сущностями внутри бизнес-логики (а-ля Datomic Pull API)..
Но совершенно точно не перейду на модель огромного графа изменяемых объектов (которую, судя по всему Хориков считает идеально чистой).
При том у Хорикова в самом примере есть противоречие:
С одной стороны, он пишет:
And the difference here is the IStudentRepository interface. The domain class simply wouldn’t need to work with this interface in a setting with no database.
Но с другой стороны, в примере он использует репоз для того, чтобы обеспечить уникльность емейла студента. И вот куда он засунет поиск студента по емейлу? В
class Domain(val students: Set<Student>)?Кажется, единственное разумное место, куда можно эту проверку засунуть - StudentsRepository. Где бы он не хранил свои данные - в памяти или БД.
В общем, функциональная модель не только лучше отражает модель в голове конечного пользователя, но и лучше отражает природу информационных систем.
#functional_architecture@ergonomic_code #ddd@ergonomic_code
GitHub
GitHub - d-r-q/qbit: qbit is a kotlin-multiplatform embeddable decentralized DBMS with object-relational information model
qbit is a kotlin-multiplatform embeddable decentralized DBMS with object-relational information model - d-r-q/qbit
❤4👍3
Карта канала
Добро пожаловать на канал "Эргономичный код" — канал о разработке поддерживаемых кодовых баз в общем и моём подходе к этой задаче — Эргономичном подходе.
Что такое Эргономичный подход?
По большому счёту это небольшой набор принципов, взятых в основном из классической школы TDD, функциональной архитектуры и DDD, и большой набор рецептов — моделей, методик и шаблонов —, которые позволяют команде быстро создавать кодовые базы, соответствующие этим принципам и, как следствие, лёгкие в поддержке.
Подробности на сайте Эргономичного подхода
В Эргономичном подходе есть что-то уникальное?
Да. Идея представления системы как модели её эффектов в виде диаграммы эффектов и методика проектирования на базе этой модели.
"Слова дёшевы, покажи мне код!"
Trainer Advisor — некоммерческий, но реальный (~17K строк Котлин кода, 15 таблиц, 2 настоящих пользователя, горки костылей, "компромиссных решений" и исторических наслоений) проект с открытым исходным кодом, разрабатываемый по Эргономичному подходу. В этот проект можно поконтрибьютить и на своём опыте прочувствовать работу с эргономичной кодовой базой.
Project Mariotte — минимальный демонстрационный пример кодовой базы, написанной по Эргономичному подходу, на примере операции бронирования номера в отеле
Есть что посмотреть или послушать?
Да, все мои публичные выступления собраны на одной странице
А почитать, кроме канала?
Да, в блоге
В блоге и канале есть подборки:
- Кейсы (в блоге, в канале #case@ergonomic_code)
- Примеры кода (в блоге)
- Эргономичный подход (в блоге, в канале #ergo_approach@ergonomic_code)
- Эргономичное тестирование (в блоге, в канале #ergo_testing@ergonomic_code)
- Функциональная архитектура (в блоге, в канале #functional_architecture@ergonomic_code)
- Эргономиный персистанс (в блоге, в канале #ergo_persistance@ergonomic_code)
- Что ещё почитать (в блоге, в канале #books@ergonomic_code, #posts@ergonomic_code, #papers@ergonomic_code)
- Что ещё посмотреть (в блоге, в канале #talks@ergonomic_code)
А у меня вопрос!
Приходите в группу - там целому сообществу (более 100 крутых инженеров) можно задать любой вопрос по тематике канала - Эргономичный подход, классическая школа ТДД, ФА, ФП, в целом дизайн модели и системный дизайн
Добро пожаловать на канал "Эргономичный код" — канал о разработке поддерживаемых кодовых баз в общем и моём подходе к этой задаче — Эргономичном подходе.
Что такое Эргономичный подход?
По большому счёту это небольшой набор принципов, взятых в основном из классической школы TDD, функциональной архитектуры и DDD, и большой набор рецептов — моделей, методик и шаблонов —, которые позволяют команде быстро создавать кодовые базы, соответствующие этим принципам и, как следствие, лёгкие в поддержке.
Подробности на сайте Эргономичного подхода
В Эргономичном подходе есть что-то уникальное?
Да. Идея представления системы как модели её эффектов в виде диаграммы эффектов и методика проектирования на базе этой модели.
"Слова дёшевы, покажи мне код!"
Trainer Advisor — некоммерческий, но реальный (~17K строк Котлин кода, 15 таблиц, 2 настоящих пользователя, горки костылей, "компромиссных решений" и исторических наслоений) проект с открытым исходным кодом, разрабатываемый по Эргономичному подходу. В этот проект можно поконтрибьютить и на своём опыте прочувствовать работу с эргономичной кодовой базой.
Project Mariotte — минимальный демонстрационный пример кодовой базы, написанной по Эргономичному подходу, на примере операции бронирования номера в отеле
Есть что посмотреть или послушать?
Да, все мои публичные выступления собраны на одной странице
А почитать, кроме канала?
Да, в блоге
В блоге и канале есть подборки:
- Кейсы (в блоге, в канале #case@ergonomic_code)
- Примеры кода (в блоге)
- Эргономичный подход (в блоге, в канале #ergo_approach@ergonomic_code)
- Эргономичное тестирование (в блоге, в канале #ergo_testing@ergonomic_code)
- Функциональная архитектура (в блоге, в канале #functional_architecture@ergonomic_code)
- Эргономиный персистанс (в блоге, в канале #ergo_persistance@ergonomic_code)
- Что ещё почитать (в блоге, в канале #books@ergonomic_code, #posts@ergonomic_code, #papers@ergonomic_code)
- Что ещё посмотреть (в блоге, в канале #talks@ergonomic_code)
А у меня вопрос!
Приходите в группу - там целому сообществу (более 100 крутых инженеров) можно задать любой вопрос по тематике канала - Эргономичный подход, классическая школа ТДД, ФА, ФП, в целом дизайн модели и системный дизайн
Эргономичный подход
Способ быстро создавать кодовые базы, которые легко менять для поддержки новых требований
🔥6❤4👍3
Привет!
Наконец-то опубликовали официальную запись моего доклада "Структурный дизайн. Древний секрет простого и быстрого кода" с Joker '24 ! 🎉🎉🎉
#talks@ergonomic_code #ergo_approach@ergonomic_code #functional_architecture@ergonomic_code #structured_design@ergonomic_code
Наконец-то опубликовали официальную запись моего доклада "Структурный дизайн. Древний секрет простого и быстрого кода" с Joker '24 ! 🎉🎉🎉
#talks@ergonomic_code #ergo_approach@ergonomic_code #functional_architecture@ergonomic_code #structured_design@ergonomic_code
YouTube
Алексей Жидков — Структурный дизайн. Древний секрет простого и быстрого кода
Подробнее о Java-конференциях:
— весной — JPoint: https://jrg.su/gTrwHx
— осенью — Joker: https://jrg.su/h7yvG4
— —
Скачать презентацию с сайта Joker — https://jrg.su/TWOpZS
В докладе — краткий экскурс в структурный дизайн и, в частности, в понятие сбалансированных…
— весной — JPoint: https://jrg.su/gTrwHx
— осенью — Joker: https://jrg.su/h7yvG4
— —
Скачать презентацию с сайта Joker — https://jrg.su/TWOpZS
В докладе — краткий экскурс в структурный дизайн и, в частности, в понятие сбалансированных…
👍21🎉13🔥3
Привет!
Периодически гипотезы, лежащие в основе ЭП, рушатся о жестокую реальность промышленной разработки, что приводит к кризисам ЭП, которых уже было три штуки: раз по мотивам проекта Barcoder (решение), два (решение) и три (решение - нафик ООД, ДДД и private внутри одного репоза😀) - по мотивам #project_e.
И вот по мотивам #project_r за последние 5 дней у меня случился и благополучно разрешился очередной кризис ЭП:)
В связи с чем у меня пачка новостей.
Книга
Это уже новость второй свежести, но для контекста надо проговорить - я договорился с менеджером проектов издательства Питер начать с апреля плотную работу над книгой про ЭП. Так что надеюсь, на горизонте пары лет книга увидит свет.
Отказ от ФА
Номинально самая большая новость - я решил отказаться от ФА (которая когда-то была одним из трёх столпов ЭП).
Но по сути ничего не меняется - ЭП всё так же предполагает использование неизменяемых структур данных и максимально возможное разделение логики и ио.
Это просто признание реальности, что в ЭП, который начинался как сильно функциональный, я методично отказываюсь от отличительных черт ФА/ФП:
1. уже очень давно я отказался от монад и ROP-а в пользу защитных условий
2. затем я затащил операции в императивную оболочку
3. во многом по мотивам Проекта Р я вернул в милость выброс исключений вместо возвращения Result
4. по мотивам Проекта Р, я утащил сбалансированную форму системы с архитектурного уровня системы, на локальный уровень отдельных методов
Отказ от SDJ как дефолтной технологии работы с БД
А вот по сути самое больше изменение - я решил отказаться от SDJ в качестве дефолта для работы с БД.
Это всё ёще допустимый в рамках ЭП т.к. его всё ещё легче "продать" заказчикам и коллегам, но по умолчанию я теперь предлагаю использовать какой-то легковесный DSL - jooq или Exposed, ещё не решил что именно.
Это опять же обусловлено опытом Проекта Р - там у меня львиная доля запросов чтения рукописные, потому что SDJ не в состоянии эффективно доставать данные этого проекта, а после того, как мне пришлось ещё и два кастомных метода сохранения написать - стало понятно, что я борюсь с технологией. Этому решению так же поспособствовали пост из канала одного из участников нашей группы.
И решение перейти на UUID-ы, которое так же было обусловлено опытом разработки Проекта Р, где надо сетапать огромные графы объектов в тестах и с генераций ИДов на уровне БД это очень сложно.
Новая версия описания Эргономичной архитектуры
На мой взгляд самая крутая новость - я выложил новый подход к описанию ЭА.
По сути там ничего не изменилось, изменилась только подача.
Но эта новая подача мне настолько нравится, что я решил показать самый первый черновик.
Основная фишка - я отказался от попытки быть как все и уместить архитектуру на одну картинку и ввёл идею проекций. Их три:
1. проекция структуры данных (модель данных) - тут про агрегаты и связи между ними
2. проекция состояния (объектная модель) - тут про объекты в рантайме (порты, операции, ресурсы) и связи между ними
3. проекция структуры поведения (процедурная модель) - тут про методы и связи между ними
Плюс я туда сразу накидал кучу примеров (пока на словах😕), а так же процессы построения всех этих структур и итоговой архитектуры.
Над единой картинкой я тоже ещё подумаю: кажется, судя по проектам физических изделий, где есть проекции по плоскостям плюс изометрия или проекты зданий, где есть тоже должны быть разные проекции и разные слои (с электропроводкой, например) - для ЭА тоже можно что-то такое сделать.
И возвращаясь к книге - эта статья по сути - четверть книги. Заполнить там пробелы, добавить примеры и теоретическая часть по ЭА готова. Вспоминая про бейзкамповский Hill Chart, у меня сейчас такое ощущение, что я достиг холма реализации ЭА и дальше только дело техники. Лишь бы очередной проект не зафейлил очередную гипотезу😄
#the_book@ergonomic_code #functional_architecture@ergonomic_code #ergo_arch@ergonomic_code #ergo_persistance@ergonomic_code #spring_data_jdbc@ergonomic_code
Периодически гипотезы, лежащие в основе ЭП, рушатся о жестокую реальность промышленной разработки, что приводит к кризисам ЭП, которых уже было три штуки: раз по мотивам проекта Barcoder (решение), два (решение) и три (решение - нафик ООД, ДДД и private внутри одного репоза😀) - по мотивам #project_e.
И вот по мотивам #project_r за последние 5 дней у меня случился и благополучно разрешился очередной кризис ЭП:)
В связи с чем у меня пачка новостей.
Книга
Это уже новость второй свежести, но для контекста надо проговорить - я договорился с менеджером проектов издательства Питер начать с апреля плотную работу над книгой про ЭП. Так что надеюсь, на горизонте пары лет книга увидит свет.
Отказ от ФА
Номинально самая большая новость - я решил отказаться от ФА (которая когда-то была одним из трёх столпов ЭП).
Но по сути ничего не меняется - ЭП всё так же предполагает использование неизменяемых структур данных и максимально возможное разделение логики и ио.
Это просто признание реальности, что в ЭП, который начинался как сильно функциональный, я методично отказываюсь от отличительных черт ФА/ФП:
1. уже очень давно я отказался от монад и ROP-а в пользу защитных условий
2. затем я затащил операции в императивную оболочку
3. во многом по мотивам Проекта Р я вернул в милость выброс исключений вместо возвращения Result
4. по мотивам Проекта Р, я утащил сбалансированную форму системы с архитектурного уровня системы, на локальный уровень отдельных методов
Отказ от SDJ как дефолтной технологии работы с БД
А вот по сути самое больше изменение - я решил отказаться от SDJ в качестве дефолта для работы с БД.
Это всё ёще допустимый в рамках ЭП т.к. его всё ещё легче "продать" заказчикам и коллегам, но по умолчанию я теперь предлагаю использовать какой-то легковесный DSL - jooq или Exposed, ещё не решил что именно.
Это опять же обусловлено опытом Проекта Р - там у меня львиная доля запросов чтения рукописные, потому что SDJ не в состоянии эффективно доставать данные этого проекта, а после того, как мне пришлось ещё и два кастомных метода сохранения написать - стало понятно, что я борюсь с технологией. Этому решению так же поспособствовали пост из канала одного из участников нашей группы.
И решение перейти на UUID-ы, которое так же было обусловлено опытом разработки Проекта Р, где надо сетапать огромные графы объектов в тестах и с генераций ИДов на уровне БД это очень сложно.
Новая версия описания Эргономичной архитектуры
На мой взгляд самая крутая новость - я выложил новый подход к описанию ЭА.
По сути там ничего не изменилось, изменилась только подача.
Но эта новая подача мне настолько нравится, что я решил показать самый первый черновик.
Основная фишка - я отказался от попытки быть как все и уместить архитектуру на одну картинку и ввёл идею проекций. Их три:
1. проекция структуры данных (модель данных) - тут про агрегаты и связи между ними
2. проекция состояния (объектная модель) - тут про объекты в рантайме (порты, операции, ресурсы) и связи между ними
3. проекция структуры поведения (процедурная модель) - тут про методы и связи между ними
Плюс я туда сразу накидал кучу примеров (пока на словах😕), а так же процессы построения всех этих структур и итоговой архитектуры.
Над единой картинкой я тоже ещё подумаю: кажется, судя по проектам физических изделий, где есть проекции по плоскостям плюс изометрия или проекты зданий, где есть тоже должны быть разные проекции и разные слои (с электропроводкой, например) - для ЭА тоже можно что-то такое сделать.
И возвращаясь к книге - эта статья по сути - четверть книги. Заполнить там пробелы, добавить примеры и теоретическая часть по ЭА готова. Вспоминая про бейзкамповский Hill Chart, у меня сейчас такое ощущение, что я достиг холма реализации ЭА и дальше только дело техники. Лишь бы очередной проект не зафейлил очередную гипотезу
#the_book@ergonomic_code #functional_architecture@ergonomic_code #ergo_arch@ergonomic_code #ergo_persistance@ergonomic_code #spring_data_jdbc@ergonomic_code
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥6👍4❤2
Привет!
Heartbeat-пост.
Я жив. И канал жив. И Эргономичный подход жив.
Затишье в последнее время связано в основном с тем, что я в Trainer Adviser пилю интеграцию с ical-календарями.
Там не то чтобы прям рокетсайнс, но уже и не совсем тривиальный круд - будет больше примеров нетривиального кода по ЭП.
Но это я днём руками работают. А ночью думаю. Что взять на замену функциональной архитектуре. И у меня тут появилась идея CQTS Principle - Command-Query-Transformation Principle.
Берём старый добрый CQS скрещиваем его со сбалансированной формой системы и получаем профит. Это пока мысль в слух - не знаю стоит ли дальше этот термин педалировать или ну его.
#trainer_advisor@ergonomic_code #ergo_approach@ergonomic_code #functional_architecture@ergonomic_code #structured_design@ergonomic_code
Heartbeat-пост.
Я жив. И канал жив. И Эргономичный подход жив.
Затишье в последнее время связано в основном с тем, что я в Trainer Adviser пилю интеграцию с ical-календарями.
Там не то чтобы прям рокетсайнс, но уже и не совсем тривиальный круд - будет больше примеров нетривиального кода по ЭП.
Но это я днём руками работают. А ночью думаю. Что взять на замену функциональной архитектуре. И у меня тут появилась идея CQTS Principle - Command-Query-Transformation Principle.
Берём старый добрый CQS скрещиваем его со сбалансированной формой системы и получаем профит. Это пока мысль в слух - не знаю стоит ли дальше этот термин педалировать или ну его.
#trainer_advisor@ergonomic_code #ergo_approach@ergonomic_code #functional_architecture@ergonomic_code #structured_design@ergonomic_code
GitHub
Commits · ergonomic-code/Trainer-Advisor
Информационная система йогатерапевта и демонстрационный проект Эргономичного подхода - Commits · ergonomic-code/Trainer-Advisor
❤3👍2