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

Как класс может с кем то что то сделать? Ты о статических методах класса?
Фреймворки не могут научить ООП.
То что ты описал, эту процедурку, так делать в рамках ООП не правильно, и это четко указано в литературе, кто интересуется прекрасно это понимает.


_____________
There never was a struggle in the soul of a good man that was not hard

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

в чем сложность?

_____________
There never was a struggle in the soul of a good man that was not hard

Для меня, ежедневно проводящему кучу времени на форуме уже 10 лет, это очевидно. И не только на этом форуме, кстати. Так что могу претендовать на статистику. :D

Хорошо, коли так. НО причем тут тесты? TDD крутая и очень полезная штука, однако как он коррелирует с принципами ООП? При всей его крутизне, это совсем не обязательная вещь.

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

Однако делают. Одна только Active Record чего стоит. Хоть в Yii, хоть в Ларе.

Не будет, а может. Это разные вещи. SRP конечно никто не отменял, но для DDD этот принцип не совсем подходит. Ибо он большей частью касается именно классов, сиреч реализации. А проектирование не должно привязываться к реализации.

Вот если принять как должное, что объект - субстанция самостоятельная, тогда можно сначала спроектировать домен из объектов, а потом написать классы, которыми эти объекты будут управлять. По сути объект, это набор данных и ключ к классу. Что в классе творится, объект знать не должен. И не класс изменяет объект (VO вообще изменять нельзя), а объект сам изменяет свое состояние с помощью класса. Вот это понять трудно обычно, но когда люди это понимают, остальные вопросы отваливаются сами собой. Я на работе это проверил. :)

в чем сложность?

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

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Объекты должны распологаться как в любом другом проэкте
Различия только в том, что в DDD только сождаётся дополнительная логическая прослойка, которая соответствует понятиям и функциям которые используются в реальной жизни.
То есть возьмём к примеру покупку в магазине. Имеется Покупатель, Магазин, Товар, Касса.
В DDD при описание процесса Продажа надо всё это описать, даже если у тебя нет ещё не конкретного товара и не покупателя.
Часто в DDD используется top to down программирование, то есть когда ты программируешь процесс не имея ещё конкретных классов. Таким образом у тебя и создаётся именно эта прослойка.
Как правили создают класс с названием процесса и в конструкторе передают интерфейсы всех участвующих в процессе актёров.
В методе который описывает процесс (как правило с названием run, или process) ты работаешь с интерфейсами и вызывая методы интерфейсов описываешь процесс, который ты хочешь вызывать.
Так же можно процесс назвать не run, или process, а рельным названием этого процесса, к примеру покупка, продажа, и.т.д...
После этого ты начинаешь уже создавать или брать уже имеющиеся объекты и подгонять их под интерфейсы которые ты используешь в твоём процессе при передаче в конструкторе.
И на конец ты при использование процесса должен всего лишь засунуть эти объекты в конструктор и вызвать нужную методу процесса.
Вот и всё.
Какую библиотеку ты потом используешь уже роли не играет и описанная в твоём процессе логика может вызываться вместе в любой библиотеке и даже использоваться как микросервис для вызова на уровне любых языков программирования.



_____________
↓↓↓↓↓↓↓↓↓↓
ответ может быть здесь
или в mysql_error();