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

Ну, это все трение...

И потом роды. Иногда продукта, а иногда только вОды

Ну по описанию это просто какой-то OpenMpi(которому уже 100500 лет), но, подозреваю, что изначально имелось в виду что-то типа https://darklang.com

Problem solving не равно engineering.
Я про создание артефактов и проектирование, как сущностную часть работы.

Привет. Веб проект.

сейчас на проекте используем почти полностью anemic design model, чуток ddd.

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

Вопрос: если у энтити есть какой-то тип, по которому из какого-нить registry можно вытащить definition для этого типа (всякая инфа по нему), то насколько метод в энтити, отдающий этот самый definition (вытягивая из registry по собственному типу) влазит в DDD?

Вопрос, зачем? Зачем из registry вытаскивать definition entity? Зачем вообще definition энтити в registry? Но если вы и сможете объяснить причины, то такого метода у энтити, особенно в соответствии с ddd, быть точно не должно.

Не дефинишен энтити, а дефинишен ТИПА энтити.

Там может быть любая инфа, которая касается конкретно ТИПА

Я это и имел ввиду. Зачем?

Зачем нужна эта инфа? Вам рефлексии не хватает?

И кому нужна эта инфа?

Ну, допустим есть какая-то система, отвечающая за опции (опция равно какая-то фича, которую обычно дают с какой-то подпиской. Например, в плане за 9 баксов есть фича 1, а в плане за 99 есть фича 2 и 3). Есстественно сама система ничего не знает, какие там опции есть в клиентском коде.

Она умеет с ними работать - создавать, вытягивать, удалять, менять - через интерфейсы. Собственно клиентский код регистрирует типы опций через registry - те самые фичи 1, 2 и 3.

Фича 1 использует один обьект с данными и своей сериализацией, фича 2 - другой, фича 3 - третий.

Фича 1 предоставляет интерфейс для работы с ней извне, фича 2 - другой, фича 3 - третий

Вот и каждая фича - имеет свой definition, который регистрируется в registry

А теперь у инстенса Option, допустим, есть поле type - фича_1, фича_2, фича_3. По этому идентификатору можно вытащить из registry ее definition - что бы работать с ним в дальнейшем.

По моему это ddd в полном его проявлении)

Всё плохо.

Во первых, Тип Entity - это класс. Определение (definition) класса - это сам класс, узнать всю информацию о классе можно с помощью рефлексии.

Например, конкретная фича (фича под номером 1) - это объект (экземпляр)  класса Фича. Поскольку класс Фича одновременно ещё и тип сущности (энтити), то получить определение этого типа можно с помощью рефлексии.

Вопрос, какая нужна информация о типе сущности, которую нельзя получить с помощью рефлексии?

Причем тут рефлекция? Каким образом имея поле "type" со значением "фича_1" мне рефлекция поможет вытащить конфигурацию для этого типа, вызвать фабрику каких-то обьектов, присущим этому типу (это реальный юс кейс, детали упускаются) или узнать, как и во что десериализировать данные из поля "data"?

id | type | data
1  | f1       | 123
2  | f2       | {"sections": ["one", "two"]}
3  | f1       |  877

Имея такие данные, каким образом мне десириализировать data в обьект типа LimitedOptionData для опций 1 и 3, и в обьект типа SectionedOptionData  для опции 2?

Каким образом мне создать обьекты типа  F1OptionPresenter для опций 1 и 3, и обьект типа F2OptionPresenter для опции 2?

Рефлекция тут ни при чем.

id | type | data
1  | f1       | 123
2  | f2       | {"sections": ["one", "two"]}
3  | f1       |  877

Вы в каком классе учитесь?

Ясно) Подожду пока вы загуглите что такое рефлекция, приходите как только.

Я ожидал что после примера выше вопрос об рефлекции отпадет сам собой, но нет. Даже на второй раз не отпал.