Где Боб Мартин ссылался на Event storming? В Clean architecture словом actor Боб пользуется для краткости, заменяя им слова user, stakeholder и их группы. А стейкхолдеры это и people тоже.
"Мы же не будем email и sms пихать в один класс. Для таких случаев подойдет старый, добрый принцип описанный в этой статье" - вам Мартин буквально сказал, что этот старый добрый принцип понят неправильно и SRP про другое. SRP != неправильно трактованный SRP. Я не против существования старой трактовки, хоть и она вызывает определенные вопросы, но она НИКАК больше не принадлежит SOLID.
Потому что он про совершенно другую вещь. Принцип про то, что только один человек или одна группа людей может задать такие требования, что придется вносить изменения в этот класс. Не про то, что класс не может выполнять более одной функции
SRP описан неверно и приведен неверный пример, собственно, как и почти везде в интернете. В последних изданиях «Чистой архитектуры» Боб Мартин извиняется за слово «причина» в определении, потому что подавляющим большинством оно было понято неправильно. А затем дает новое определение «перед каждым классом должен быть ответственен только один актор» - что делает пример из статьи (и из большинства других статей) бесполезным. Тем не менее, даже с таким определением этот принцип почти никогда нельзя соблюсти из-за наличия функциональных и не функциональных требований, т.е. актора всегда два: заказчик, который просит перекрасить кнопку, и какая-нибудь кор-команда, которая просит тебя переписать код под новую мажорную версию языка
Кажется, миллиард определений одного и того же принципа это не проблема любителей холиварить, а проблема автора этого принципа
Про перевод согласен.
Где Боб Мартин ссылался на Event storming? В Clean architecture словом actor Боб пользуется для краткости, заменяя им слова user, stakeholder и их группы. А стейкхолдеры это и people тоже.
"Мы же не будем email и sms пихать в один класс. Для таких случаев подойдет старый, добрый принцип описанный в этой статье" - вам Мартин буквально сказал, что этот старый добрый принцип понят неправильно и SRP про другое. SRP != неправильно трактованный SRP. Я не против существования старой трактовки, хоть и она вызывает определенные вопросы, но она НИКАК больше не принадлежит SOLID.
Потому что он про совершенно другую вещь. Принцип про то, что только один человек или одна группа людей может задать такие требования, что придется вносить изменения в этот класс. Не про то, что класс не может выполнять более одной функции
SRP описан неверно и приведен неверный пример, собственно, как и почти везде в интернете. В последних изданиях «Чистой архитектуры» Боб Мартин извиняется за слово «причина» в определении, потому что подавляющим большинством оно было понято неправильно. А затем дает новое определение «перед каждым классом должен быть ответственен только один актор» - что делает пример из статьи (и из большинства других статей) бесполезным. Тем не менее, даже с таким определением этот принцип почти никогда нельзя соблюсти из-за наличия функциональных и не функциональных требований, т.е. актора всегда два: заказчик, который просит перекрасить кнопку, и какая-нибудь кор-команда, которая просит тебя переписать код под новую мажорную версию языка