цена это функция
я склоняюсь больше к слову "договор максимальной цены"
DDD: Как правильно работать с контекстами ?
- Автор темы Gutsy
- Дата начала
Вурдалак
Продвинутый новичок
Есть разные аспекты одних и тех же понятий на естественном языке. Бизнесовый, философский, потребительский, etc. Поэтому просто выкидывать такие определения без привязки к контексту — это сотрясать воздух.
цена это некая функция которая зависит оп продавца, покупателя, количества и момента времени. iphone7 у разных продавцов для разных людей стоит по разному, мне как простому смертному 700 в магазине А, тебе как постоянному покупателю за 650 в магазине А, а ему как мужу дочери двоюродного брата продавца в магазина А по закупочной.
если продали товар за 42, придется отчитаться перед поставщиком, почему 42. нужно найти ту самую id цены в которой указаны условия.
если продали товар за 42, придется отчитаться перед поставщиком, почему 42. нужно найти ту самую id цены в которой указаны условия.
camohob
Новичок
Есть у нас в системе такая штука, как фотографии отеля. Они имеют какие-то метаданные(название, описание, приоритет, ...) и сам файл. Метаданные хранятся в MySQL, а вот файлы в мускуле хранить идея плохая - поэтому мы выбрали GridFS(но на самом деле не важно, хоть просто в FS).
Т.е., получается, что у нас доменная модель фотографии отеля мапится уже на два разных хранилища.
Таких примеров в системе будет много, где то будут агрегаты, часть которых проще грузить из кэша, например...
З.Ы.: мы с @Gutsy над одним проектом работаем)
camohob
Новичок
Вот, именно к ручному датамаперу мы и пришли. Попробовали сделать конвертацию сущностей доктрины в доменные модели и агрегаты прямо в репозитории - ничего хорошего не вышло... ((
Может есть у кого опыт таких извращений?) Дайте посмотреть на реализацию такого "датамапера", плиз
Вурдалак
Продвинутый новичок
Я боюсь, что тут просто подобрана ужасная терминология. Продали по $42 — это и есть цена. А подробности формирования цены можно было бы узнать, например, из offer'а. И называть это «ценой» для меня по меньшей мере странно.
Вурдалак
Продвинутый новичок
Сам файл? В смысле blob? Он в виде свойства у модели что ли?
Почему в модели не может быть просто имя файла или id фотографии?
даже если тебе предложениями легче думать, вопрос "какое из предложений" остался
camohob
Новичок
Да, сам файл в свойстве(по факту это конечно же ссылка на "ленивый" объект). Почему так?
1. Потому что файл - неотъемлемое свойство модели и модель без него не является валидной.
2. В контроллере отсутствуют операции по поискам файла в каком-либо хранилище, объект в свойстве файла описывает некий интерфейс, который умеет файл представлять в виде строки или ресурса. Таким образом мы в любой момент можем заменить хранилище файлов и не переписывать все контроллеры.
И сейчас это дело организовано через кастомный тип доктрины, DM туда просовывается в билдере бандла:
PHP:
class UploadMongoType
{
/** @var DocumentManager */
protected $dm;
....
/**
* @param mixed $value
* @param \Doctrine\DBAL\Platforms\AbstractPlatform $platform
* @return null
* @throws \Doctrine\DBAL\Types\ConversionException
*/
public function convertToDatabaseValue($value, AbstractPlatform $platform)
{
if (empty($value)) {
return null;
}
if ($value instanceof UploadMongo) {
if ($this->dm->getUnitOfWork()->getDocumentState($value) === UnitOfWork::STATE_NEW) {
$this->dm->persist($value);
}
$this->dm->flush();
return $value->getId();
}
throw ConversionException::conversionFailed($value, self::NAME);
}
/**
* @param mixed $value
* @param \Doctrine\DBAL\Platforms\AbstractPlatform $platform
* @return null
*/
public function convertToPHPValue($value, AbstractPlatform $platform)
{
if (empty($value)) {
return null;
}
return $this->dm->getReference(UploadMongo::class, $value);
}
}Оно работает, но выглядит как костыль. Хочется именно отделить доменные Модели от ОРМ.
Вурдалак
Продвинутый новичок
Я не знаю какие там у тебя вопросы остались, но я вёл речь про терминологию, которая тебя, судя по всему, как раз безразлична.
да, по разным договорам, предложениям как хочешь, значение одно а цена как единица с указанием "что за цена" разная!
намешал все до кучи, не поняв смысла.
Вурдалак
Продвинутый новичок
Это культ Карго. Как уже отметили, это свойство никак в бизнес-логике не участвует, бессмысленно его туда тащить.
Я очень рекомендую попробовать записывать события в модели: https://phpclub.ru/talk/threads/Как...trine-analogue-ручками-etc.82411/#post-747858
Тогда станет понятно, что главное в сущности — это именно отклик в виде события, а не то, какие там внутри свойства. И я боюсь, что наличие blob'а с изображением в сущности никак на отклик влиять не будет совершенно.
Второй момент, на который я хочу обратить внимание — это разделение чтения и записи (CQRS). Вот это рассуждение на тему того какие свойства могут понадобится в момент чтения будет очень сильно мешать для реализации чистой модели.
camohob
Новичок
т.е. вот такая логика?
- при добавлении фотки - мы этот файл где-то в контроллере или обработчике команды записываем в GridFS - получаем id и создаем модель фотографии уже с этим id.
- при чтении фотки - опять же в контроллере мы идем в GridFS, ищем файл, генерируем линк на него - показываем
- при удалении фотки - в контроллере или обработчике команды удаляем файл из GridFS и модель.
Получается что просто удаления модели недостаточно чтобы были соблюдены все бизнес-правила. Бизнес правило просит удалять фотографию вместе с файлом.. а мы эту логику выносим из домена?
Или бизнес ничего не знает о файлах - для него только фотка удаляется, а файл - это уже детали реализации, так?
camohob
Новичок
религия меланезийских аборигенов? ))
camohob
Новичок
вот, а как же в этом случае мапить read и write модели на одни и те же данные? или read модель строить из write модели, а мапить только её?
camohob
Новичок
но именно так она и стала анемичной) разве только простейшей валидацией полей и выпуском событий она должна заниматься?