бро это пакет во первых

ramsey/uuid

И никаких коллизий?

когда пишут доку не прдполагают как именно у тебя поставлен пых и другое

На все 100% доверяете?

И никаких коллизий?

ну у меня сущностей не очень много, но коллизий не было

там ведь энтропия дикая

и прям написано надо поставить mbstring

или gd

На все 100% доверяете?

5.3x10^36 вариантов

или zip

канешн)

5.3x10^36 вариантов

ну time-based может коллизнуть

ну потому я и использую ууид)

На все 100% доверяете?

вроде норм) The number of random version 4 UUIDs which need to be generated in order to have a 50% probability of at least one collision is 2.71 quintillion. This number is equivalent to generating 1 billion UUIDs per second for about 85 years. https://en.wikipedia.org/wiki/Universally_unique_identifier#Collisions

или васкулит

http://php.net/manual/ru/mbstring.installation.php

см. выше предлагают гуглить

Кто как генерит unique id всякие?

либо uuid, либо тикет сервер

можно еще как на ютубчике

можно еще как на ютубчике

а как на ютьюбчике?

загугли, на хабре была статья недавно

Я 666ой подписант)

я 666

Демон

изыди :D

class NotBlank extends Constraint { const IS_BLANK_ERROR = 'c1051bb4-d103-4f74-8988-acbcafc7fdc3'; … Не подскажете по какому принципу генерируется код ошибок в Symfony Constraint? ‘c1051bb4-d103-4f74-8988-acbcafc7fdc3’ ???

class NotBlank extends Constraint { const IS_BLANK_ERROR = 'c1051bb4-d103-4f74-8988-acbcafc7fdc3'; … Не подскажете по какому принципу генерируется код ошибок в Symfony Constraint? ‘c1051bb4-d103-4f74-8988-acbcafc7fdc3’ ???

Uuid

Спасибо, что-то вылетело из головы

Уважаемые знатоки. Есть тут те, кто угорает по Symfony и DDD одновременно? Допустим есть Business Entity "Employable" у которого есть такие комплексные VO как Address(string country, string city, string postcode, string street), PaymentData(PaymentType type, InvoiceData data). Такие VO хранятся в БД в виде JSON объектов. Как вы бы организовали эти VO? 1) такие VO реализуют интерфейс \JsonSerializable и их кодирование происходит через json_encode где-то в ORM 2) такие VO не делают ничего такого и их кодированием и декодированием занимаются внешние сериализаторы и нормализаторы? 3) третий вариант

Уважаемые знатоки. Есть тут те, кто угорает по Symfony и DDD одновременно? Допустим есть Business Entity "Employable" у которого есть такие комплексные VO как Address(string country, string city, string postcode, string street), PaymentData(PaymentType type, InvoiceData data). Такие VO хранятся в БД в виде JSON объектов. Как вы бы организовали эти VO? 1) такие VO реализуют интерфейс \JsonSerializable и их кодирование происходит через json_encode где-то в ORM 2) такие VO не делают ничего такого и их кодированием и декодированием занимаются внешние сериализаторы и нормализаторы? 3) третий вариант

@andrewDemb

Уважаемые знатоки. Есть тут те, кто угорает по Symfony и DDD одновременно? Допустим есть Business Entity "Employable" у которого есть такие комплексные VO как Address(string country, string city, string postcode, string street), PaymentData(PaymentType type, InvoiceData data). Такие VO хранятся в БД в виде JSON объектов. Как вы бы организовали эти VO? 1) такие VO реализуют интерфейс \JsonSerializable и их кодирование происходит через json_encode где-то в ORM 2) такие VO не делают ничего такого и их кодированием и декодированием занимаются внешние сериализаторы и нормализаторы? 3) третий вариант

@oop_ru

Хотя *thinking*

Уважаемые знатоки. Есть тут те, кто угорает по Symfony и DDD одновременно? Допустим есть Business Entity "Employable" у которого есть такие комплексные VO как Address(string country, string city, string postcode, string street), PaymentData(PaymentType type, InvoiceData data). Такие VO хранятся в БД в виде JSON объектов. Как вы бы организовали эти VO? 1) такие VO реализуют интерфейс \JsonSerializable и их кодирование происходит через json_encode где-то в ORM 2) такие VO не делают ничего такого и их кодированием и декодированием занимаются внешние сериализаторы и нормализаторы? 3) третий вариант

Если мы говорим за ORM, то доктрина собирает embedded объекты рефлексией. И ей на json, не json всё равно. Можно, конечно, ввести свой тип и сериализовать там. Но это не отличается от сериализации/десериализации самому. Если работать без ORM, то если делать объект ответственным за свою сериализацию, то нужно и десериализацию на него ложить. А это только статика (fromData()), что не очень. Конечно, можно сделать конструктор с array в аргументе и именованный конструктор (статика), но тоже не ок. Остаётся ответственный сериализатор.

Если мы говорим за ORM, то доктрина собирает embedded объекты рефлексией. И ей на json, не json всё равно. Можно, конечно, ввести свой тип и сериализовать там. Но это не отличается от сериализации/десериализации самому. Если работать без ORM, то если делать объект ответственным за свою сериализацию, то нужно и десериализацию на него ложить. А это только статика (fromData()), что не очень. Конечно, можно сделать конструктор с array в аргументе и именованный конструктор (статика), но тоже не ок. Остаётся ответственный сериализатор.

Спасибо. А на сколько вообще богоугодно в симфони не пользоваться ORM? просто пока мне кажется что для таких вещей оно больше мешает, чем помогает

Можно делать константы в dto, около FIELD_* которые будут в jsonSerialize, тогда сериализатор будет использовать для сериализации json encode, а при десериализации конструктор, куда используя константы впихнёт параметры

и не совсем понял про "json не json"

Уважаемые знатоки. Есть тут те, кто угорает по Symfony и DDD одновременно? Допустим есть Business Entity "Employable" у которого есть такие комплексные VO как Address(string country, string city, string postcode, string street), PaymentData(PaymentType type, InvoiceData data). Такие VO хранятся в БД в виде JSON объектов. Как вы бы организовали эти VO? 1) такие VO реализуют интерфейс \JsonSerializable и их кодирование происходит через json_encode где-то в ORM 2) такие VO не делают ничего такого и их кодированием и декодированием занимаются внешние сериализаторы и нормализаторы? 3) третий вариант

3) @Embeddable в доктрине есть же

я не совсем понимаю как она разрулит какой-то комплексный VO который состоит из нескольких других VO

Спасибо. А на сколько вообще богоугодно в симфони не пользоваться ORM? просто пока мне кажется что для таких вещей оно больше мешает, чем помогает

Работаю без ORM. Сложно самому строить такие объекты, т. к. объекты имеют свою логику, и могут не позволять создавать себя в "среднем" состоянии (пример - со статусом in process, например). Поэтому тут поможет

но Entity и VO не должны иметь логики, кроме элементарной самовалидации

Вот об этом.

3) @Embeddable в доктрине есть же

Entity? Почему нет?

но Entity и VO не должны иметь логики, кроме элементарной самовалидации

анемия?)

я не совсем понимаю как она разрулит какой-то комплексный VO который состоит из нескольких других VO

тут на примерах надо

Entity? Почему нет?

ну в понятиях symfony/doctrine может быть и может. но вообще если следовать заветам фаулера и эванса, вроде как нет

ну в понятиях symfony/doctrine может быть и может. но вообще если следовать заветам фаулера и эванса, вроде как нет

так наоборот ведь

ну в понятиях symfony/doctrine может быть и может. но вообще если следовать заветам фаулера и эванса, вроде как нет

ты что-то перепутал мне кажется)

рич модели

по заветам да)

ну в понятиях symfony/doctrine может быть и может. но вообще если следовать заветам фаулера и эванса, вроде как нет

Домен имеет логику. Entity не домен?

тут на примерах надо

Скажем Address состоит из Country, City, PostalCode и Street

почему City это VO ?

это простой пример. другой пример PaymentData: PaymentType (по сути только строка) и InvoiceData, который в зависимости от выбратнного типа будет вообще разными объектами с разным набором полей

адрес прямо в доках доктрины как пример описан http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/tutorials/embeddables.html

почему City это VO ?

потому что у него есть логика самовалидации. но я сейчас стараюсь давольно радикально следовать этой философии. в рамках эксперимента, например

ERROR: S client not available

и как город себя валидирует?

Допустим он не пустой, и включон в нейки вайт-лист. это не так важно

адрес прямо в доках доктрины как пример описан http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/tutorials/embeddables.html

да, со строками все просто. я бы хотел разобраться с более заковыристым вариантом

https://paucls.wordpress.com/2017/03/04/ddd-building-blocks-value-objects/ вот вроде релевантная статейка

Спасибо

непустой город это разве не валидность адреса?)

и белый список чего? просто городов?

или городов допустимых в адресе?

непустой город это разве не валидность адреса?)

допустим их только два: москва и питер.

или городов допустимых в адресе?

городов допустимых в системе

или городов допустимых в адресе?

AddressCity/City

fesor спит, можно пофилософствовать

ну у тебя vo - адрес, он и валидирует и знает каким ему быть

нет

ладно)

он знает что в нем должен быть город

город это некоторое важное для системы значение

а город знает каким ему быть для адреса?))

оно может быть Москва или Питер.

город знает каким ему можно быть вообще

в рамках конкретного домена у нас только два города, например

Alan я понимаю, что пример притянут за уши, но это намеренно

а в другом домене как этот город будет себя вести?)

это простой пример, второй пример с PaymentData выглядит более оправдано

а в другом домене как этот город будет себя вести?)

в другом домене - другой City

свой

то есть тот City это AdressCity ?)

ведь там он себя ведет соответственно домену