В какой-то одной парадигме реализовывать систему может оказаться трудно, поэтому и был создан принцип CQS, позволяющий использовать преимущества обоих парадигм, как OOP, так и FP, - эта тема уже затрагивалась:
https://www.tgoop.com/emacsway_log/265

Был вопрос о том, как выглядят доменные модели в функциональной парадигме:
- https://github.com/swlaschin/DomainModelingMadeFunctional

- https://github.com/swlaschin/Railway-Oriented-Programming-Example

- https://github.com/swlaschin/RailwayOrientedProgramming

Ряд других примеров для курсов и воркшопов:
- https://github.com/swlaschin?tab=repositories

На Idris:
- https://github.com/andorp/order-taking

На данном этапе у нас должны получиться следующие архитектурные артефакты:

1. Диаграммы трассировки требований.

Я использую Motivation View Points.

2. EventStorming диаграммы.

Я использую "C.1.10. Business Process Cooperation Viewpoint".

Подробнее здесь.

Шпаргалки по EventStorming здесь.

3. Context Map.

Я делаю как в "Model used by Jean-Baptiste Sarrodie for presentation "Enterprise Architecture Modelling with ArchiMate in an Agile at Scale Programme" (демонстрационная модель от автора OpenSource среды проектирования Archi).

Но есть и другие инструменты, перечисленные здесь.

Кстати, в тему обсуждения, доклад Сергея Баранова о восстановлении знаний об архитектуре системы:

Доклад
- https://www.youtube.com/live/4SEe2bx7090

Презентация
- https://www.tgoop.com/microservices_arch/531

Оказывается, в Archi вполне нормально можно вести бэклог разработки (используя Canvas).

продолжение https://miralina.substack.com/p/2

https://bessey.dev/blog/2024/05/24/why-im-over-graphql/
Просто прекрасная статья о сложностях GraphQL vs REST

Не перестаю удивляться народной мудрости. Галера - очень меткая (хотя и сатирическая) метафора для ИТ-проекта.

Гребцам нужно догрести из пункта А в пункт Б.

Представим, что конструкция дала течь. Обратите внимание, что по отношению к главному инструменту управления сложностью, абстракции, применяют такой же термин - "протекание". А все, что протекает, может потонуть. В чем может потонуть абстракция? В сложности (нерелевантных деталей), где "плавучесть" абстракции ограничена возможностями краткосрочной памяти человека.

Итак, конструкция протекает, наполняется водой (сложностью). Судно погружается, сила сопротивления движению растет. Если не предпринять меры по борьбе за живучесть судна, то сила тяжести превзойдет силу плавучести (правильней было бы сказать - выталкивания, гидростатическую подъемную силу).

То же самое происходит и с рентабельностью проекта.

И как показывает статистика, затопление происходит обычно в геометрической прогрессии.

Для борьбы за живучесть судна были придуманы водонепроницаемые переборки, которые позволяют остановить затопление судна (как и Bounded Context).

Но на галерах таких переборок может не быть. И вот команда стоит перед выбором - грести или спасать судно? Проблема в том, что с верхней палубы не видно того, что в трюмах воды по уши. И погружение судна в воду не так уж и заметно сверху - никто ведь не замерял осадку. И, кажется, что достаточно просто расчехлить плеть, чтоб заставить гребцов грести быстрее.

Чтобы восстановить скорость, нужно освободить судно от накопившейся сложности, а еще лучше - возвести водонепроницаемые переборки. Это означает потерять ход. Но восстановить скорость. Но это неточно. Можно и не восстановить. А вдруг не сумеют? Точно, весло так и не починили. А вдруг и нет никакой течи? А вдруг не из-за течи падение хода? А так хоть какой-то ход есть... Кажется, вон тот гребец в углу стал медленней грести. Или не стал? Замеров-то нет. Стал, вон другие галеры вырвались вперед. Точно. Ага. Нужно таки расчехлить плеть.

А может тот гребец прав, и все дело в течи? Нет, течь грести не умеет. Причем здесь течь? Где вёсла, а где эта мифическая течь... Все дело в том, кто гребёт. Точно. А про течь они все придумали. Хотят в трюм заманить. Только положи им палец в рот, ага, щас.. Некогда фигней заниматься, грести надо...

"Design and Reality: Essays on Software Design" by Mathias Verraes & Rebecca Wirfs-Brock
https://leanpub.com/design-and-reality

https://ru.singlelogin.re/book/24377478/a4e2de/design-and-reality-essays-on-software-design.html (уже устарела немного, правда).

Топ-3 задач, на которые ушло больше всего времени у Product Owners: "встречи, налаживание процессов и планирование".

При этом 17% столкнулись со сложностью "Взаимодействия с другими командами", т.е. проблемой Брукса. Встречи отнимают невероятно много ресурсов. Большинство продактов тратят на них от 40% своего рабочего времени.

А 27% столкнулись со сложностью в "бюрократии и политикой в компаниях".

При этом 23% опрошенных еще и занимается рабочими задачами в выходные.

Лишь 6% продактов уверены, что не сталкивались с признаками выгорания.

Для остальных "Работа в условиях большой нагрузки и выгорания " - главная проблема.

Общий вывод. Проблемы с точностью планирования, межкомандной коммуникативной нагрузкой, внутрикомандной когнитивной нагрузкой, сложность погружения в устройство продукта и предметную область, - являются отражением архитектурных проблем, и, прежде всего, функциональной (компонентной) декомпозиции системы.

А то, что каждый четвертый имел сложности с такими моментами, как "Бюрократия и политика в компаниях" и "Изменение процессов и продуктовой культуры в компании", отражает уже проблемы управленческие.

Обращает на себя внимание то, что среди главных проблем перечислены такие проблемы, как "большая нагрузка" и "планирование". Между этими проблемами есть связь, т.к. нагрузка является результатом планирования. Иными словами, качество решения второй проблемы является источником первой проблемы. А качество решения второй проблемы отражает архитектурное здоровье системы - чем оно ниже, тем хуже прогнозируемость планирования.

Источник:
https://devcrowd.ru/pm24/

Thanks to @nikitapinchuk

В целом опрос коррелирует с моим опросом. Общий вывод которого таков, что каждый четвертый доволен условиями работы лишь потому, что сам их создал себе. И только каждому двадцатому повезло попасть в благоприятную среду, созданную другими.

По результатам прошлогоднего опроса https://devcrowd.ru/go-2023 более 50% Golang-разработчиков неуверены в своих знаниях по архитектуре приложения и 48% - по распределенным системам.

39% изучает алгоритмы (вспомнился анекдот: "а этот готовится к собеседованию - уволить").

Каждый шестой Go-разработчик открывал в том этом году книги Роберта Мартина. Это прогресс. Еще четыре года назад было "Don't do Java in Golang!"

"Clean Architecture" и "Clean Code" - в топе, наряду с "Кабанчиком" by M.Kleppmann.

Главный мотивирующий фактор - решение интересных задач и сильная команда. Перевешивает даже зарплатные ожидания (на 2%).

О книге "Balancing Coupling in Software Design: Universal Design Principles for Architecting Modular Software Systems" by Vlad Khononov.

Эта книга об искуссте побеждать. Eric Evans говорил, что "Software design is a constant battle with complexity". И как показывает практика, далеко не все проекты на рынке одерживают победу в этой борьбе со сложностью. Стоимость разработки иногда возрастает экспоненциально, а рентабельность падает с таким же ускорением.

Для одержания победы в Самбо не нужно быть сильнее противника - достаточно противопоставить свои сильные группы мышц против его слабых групп мышц в болевом приеме.

В одном фильме красиво было сказано: "Искусство воевать заключается в том, чтобы быть сильным в нужное время в нужном месте."

Что произойдет, если атлет в фитнесс-зале во время приседания пренебрежет техникой безопасности и будет держать спину неровно? Вес штанги больше не будет равномерно распределяться по всей площади позвонка, пятно контакта уменьшится, удельная нагрузка возрастет, и предел прочности позвонка может оказаться недостаточным, чтобы выдержать вес. То же самое может происходить и с ИТ-проектом. Эта книга о том, как создать красивого атлета, а не больного человека.

Какое главное правило инвестора на фондовом рынке? Диверсификация, т.е. распределение рисков таким образом, чтобы каждая категория риска не превосходила допустимый предел финансовой устойчивости.

Плавучесть судна обеспечивается водонепроницаемыми переборками, обеспечивающими превосходство гидростатической подъёмной силы над силой тяжести воды в месте пробоины.

Видели когда-нибудь как море режет скалы? Обязательно посмотрите - вдохновляет. Стекающие капельки воды прорезают в камне бороздки и углубляют их до тех пор, пока глыба не обрушится. Капля против скалы! Вода камень точит!

Почему ледокол преодолевает толщи льда, а корабль - нет? Ледокол атакует лед в том направлении, в котором способен обеспечить силовое превосходство. Он атакует его сверху, где сила сопротивления льда наименьшая. А корабль - с торца, где силовое превосходство остается за льдом, поскольку в горизонтальной плоскости толща льда простирается на сотни километров.

Лед сильнее ледокола. Но ледокол способен создать силовое превосходство в нужное время в нужном месте. Этого достаточно, чтобы шаг за шагом проложить маршрут полностью.

Понимание этого принципа позволило человеку покорить Северный Полюс!

Высокая концентрация сложности программного кода может превосходить ограничения краткосрочной памяти человека. Победа над сложность достигается минимизацией объема программы, о котором нужно думать в конкретный момент времени, т.е. возможностью рассмотреть фрагмент сложности изолированно, чтобы при этом уровень рассматриваемой сложности не превосходил ограничения краткосрочной памяти человека.

Легко звучит. На практике этому часто препятствует то, что мы называем Coupling. Искусство управления Coupling формируется лучшими умами отрасли уже несколько десятилетий. Эта книга является наиболее полным, исчерпывающим руководством, финализирующим все достижения человечества в этой борьбе со сложностью. В борьбе, которую ведет каждый программист каждый день.

Эта книга о том, как покорить Северный Полюс в разработке программного обеспечения.

Когда кажется, что техдолг не представляет опасности.

Подборка постов, которая заменит вам прочтение пары книжек по конфликтам

За 9 лет работы мы проанализировали несколько тысяч конфликтных кейсов. На их основе получился фреймворк для работы с конфликтами, который позволяет легко анализировать любую ситуацию и быстро выбирать оптимальную стратегию коммуникации. Мы душнейшие душнилы с точки зрения системности :)

Наша система теории работает повсеместно: в огромных корпорациях и малых бизнесах, технологичных стартапах и госкомпаниях, на кассе в магазине и семейных отношениях.

Основа этой системы — «лестница», которая делит решение конфликта на 4 этапа. Давайте расскажем, какие посты помогут вам ее освоить и чувствовать себя уверенне в коммуникации👇🏻

1️⃣ Начните с поста про лестницу решения конфликта.

2️⃣ Чтобы освоить приемы для работы с эмоциями, читайте этот пост. Дали в нем 3 универсальных способа, как снять напряжение в разговоре и отрезвить собеседника.

3️⃣ Чтобы научиться уверенно доносить свои потребности и недовольство без агрессии и манипуляций, прочитайте следующие материалы. В них мы разбираем обозначение личных границ на разных кейсах и примерах:

1. Статья на VC про универсальную формулу обозначения личных границ

2. Как перестать закрывать глаза на нарушение границ

3. Почему не стоит быть «удобным» и как показывать границы на работе

4. Кейс подписчицы про смещение авторитета и критику на работе

4️⃣ Если человек нарушает ваши границы осознанно, пора их защищать. Выбирайте, каким приемом будете противодействовать манипулятору: декодирование, гиперболизация, ломание причинно-следственных связей.

5️⃣ Про финальный этап решения конфликта — сепарацию, наш тренер Михаил Ромашов рассказал в статье на VC. Читайте, чтобы научиться грамотно расставаться с людьми.

💬 Фух, ну вроде все! Изучайте и приходите практиковаться на наши открытые воркшопы 28 и 30 мая. Будем разыгрывать кейсы и обсуждать риски и возможности различных стратегий поведения.

В Обзоре судебной практики по делам, связанным с защитой прав потребителей финансовых услуг, утв. Президиумом ВС РФ 27 сентября 2017 г., отмечена позиция, что адрес проживания и номер телефона относятся к персональным данным (+ определение Судебной коллегии по гражданским делам Верховного Суда РФ от 01.08.2017 N 78-КГ17-45).

Плюс - скан с сайта РКН со страницы заполнения Уведомления о намерении обработки ПДн.

Не всё так сложно, как однозначно кажется))

Примерно так выглядит охрана Законом прав среднестатистического гражданина РФ за один день пребывания в международном роуминге. Все звонки без исключения - спам ("Who calls" распознал еще меньше, чем на скрине).

И это при том, что номер непубличный, ни в каких открытых источниках, досках объявлений, никогда не публиковался (для этих целей существует дополнительный номер). Можете представить себе масштабы торговли персональными данными в России.

Пытаюсь понять, откуда в России столько ущербных субъектов коммерческой деятельности, единственная способность которых заявить о себе - это навязывание. И откуда столько ущербных разработчиков, годящихся разве что только для клепания спам-систем.

Самая большая сложность в роуминге заключается в том, что для работы антиспам-систем требуется интернет, который предоставляется карточкой местного оператора, которая становится неактивной в момент вызова на карточку российского оператора.