есть фирст ласт в чате - есть бесполезные умозаключения ?‍♂️

именно, код на дарте бесполезный, что он есть, что его нет, результат все равно один

именно, код на дарте бесполезный, что он есть, что его нет, результат все равно один

Гыы

Пыха есть на гитхабе? о.0

Огоооооо

И давно?

весьма давно.

Пыха есть на гитхабе? о.0

https://github.com/php/php-src

Там даже обсуждения бывают и pr принимают

Но вроде там не все

Да, там совсем не все, но можно юзать для отправки pr

Но вроде там не все

Все, просто не монореп

Там чего не хватает в репе зэнд технолоджис

https://martinfowler.com/eaaCatalog/ServiceLayerSketch.gif картинка из фаулеровского сайта. а что там за RecognitionService? это просто пример сервисного класса?

https://github.com/joaomilho/Enterprise/blob/master/README.md

https://github.com/joaomilho/Enterprise/blob/master/README.md

passive agressive comment конечно топчик

беру свои слова назад, там тупо все топчик

Нужны отзывы о книге Object Thinking ?

Есть кто читал и может поделится впечатлением?

я думаю не помешает

а можно к вам с глупыми вопросами? 1. business object и domain object — это одно и тоже? 2. как правильнее происходит инициализация объекта? он сам стучиться в DAO и получает нужные данные или его билдит Сервис? вот правильна ли эта схема или нет https://www.oracle.com/ocom/groups/public/@otn/documents/digitalasset/145996.jpg

а можно к вам с глупыми вопросами? 1. business object и domain object — это одно и тоже? 2. как правильнее происходит инициализация объекта? он сам стучиться в DAO и получает нужные данные или его билдит Сервис? вот правильна ли эта схема или нет https://www.oracle.com/ocom/groups/public/@otn/documents/digitalasset/145996.jpg

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

трансфер обджект в этой схеме лишний

да и что делает create в этой схеме тож непонятно

в целом можешь почитать PoEAA фаулера, у него разбор основных паттернов работы с данными, включая доменную модель

оок, почитаю мне сейчас, для начала, хочется правильно увязать DO, DAO, DS и мульти DTO а скажи по конвенциям, как это всё именовать? допустим, у меня DO Юзер. в DS лежит таблица User делаю POJO модель User в /dao.models UserStorage в /dao UserService как репозиторий. но в какой директории правильно создавать - хз UserModel как DO UserTransportWs и UserTransportProto в /dto,transport UserAssembly в /dto правильно или что-то нужно именовать совсем иначе?

оок, почитаю мне сейчас, для начала, хочется правильно увязать DO, DAO, DS и мульти DTO а скажи по конвенциям, как это всё именовать? допустим, у меня DO Юзер. в DS лежит таблица User делаю POJO модель User в /dao.models UserStorage в /dao UserService как репозиторий. но в какой директории правильно создавать - хз UserModel как DO UserTransportWs и UserTransportProto в /dto,transport UserAssembly в /dto правильно или что-то нужно именовать совсем иначе?

UserService -> UserRepository хотя бы

UserModel -> User

короч, думай сам, тебе потом поддерживать. Главное не именуй штуки под паттерны

UserModel -> User

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

и почитай про всякие принципы типа information hiding, acyclic dependencies principle, stable dependency principle и т.д

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

они будут в разных модулях

либо тебе не нужно два класса

два класса нужны. в рантайме будут больше полей, например но пока они будут жить в одном приложении в разных неймспейсах а UserRepository в какой директории живет обычно? /repository?

я просто даже хз что ты там юзаешь, но судя по POJO ты похапэшник (или питонист)

два класса нужны. в рантайме будут больше полей, например но пока они будут жить в одном приложении в разных неймспейсах а UserRepository в какой директории живет обычно? /repository?

почитай про cohesion

так третья буква Java же

ERROR: S client not available

так третья буква Java же

перепутал буквы, сорян

короч я не буду тебя грузить штуками типа "корень агрегата" и что "интерфейс репозитория ложи рядом с корнем агрегата к которому он относится" ибо всеравно ты не будешь разбираться

да и подходы с доменной моделью не всегда оптимальны для задачи (чаще всего, но не всегда, и обычно это только OLTP на запись)

про оптимальность пока судить не могу, но вот цепочка объектов от DO до DS — пока хорошо заходит у меня голова квадратная в данный момент, да. и изучать прям сейчас не полезу. И в этом месте сейчас хочется просто «рыбы». Как правильно назвать директорию с DO и с репозиторями этих DO

про оптимальность пока судить не могу, но вот цепочка объектов от DO до DS — пока хорошо заходит у меня голова квадратная в данный момент, да. и изучать прям сейчас не полезу. И в этом месте сейчас хочется просто «рыбы». Как правильно назвать директорию с DO и с репозиторями этих DO

"как правильно называть вещи и куда их ложить" - один из самых сложных вопросов. Наряду с инвалидацией кэша

хаха. звучит как название книги ) но ведь я только про две директории спрашиваю, но не места, куда именно их потом класть

хаха. звучит как название книги ) но ведь я только про две директории спрашиваю, но не места, куда именно их потом класть

этот вопрос только кажется простым =\ Лично мне обычно отвечали на него "ну положи куда-нибудь" :D

сейчас я пытаюсь нагуглить «типовую» структуру директорий для DDD. чтоб хоть от чего-то отталкиваться (а ещё hexagonal architecture гуглится параллельно…)

сейчас я пытаюсь нагуглить «типовую» структуру директорий для DDD. чтоб хоть от чего-то отталкиваться (а ещё hexagonal architecture гуглится параллельно…)

DDD это не про репозитории :)

а про ubiquitous language

сейчас я пытаюсь нагуглить «типовую» структуру директорий для DDD. чтоб хоть от чего-то отталкиваться (а ещё hexagonal architecture гуглится параллельно…)

нет что бы почитать про low coupling/high cohesion

ни DDD ни гексагоналка не регламентируют тебе такие мелкие штуки как структура проекта

помимо слоев есть еще вертикальное разделение

по фичам типа, по контекстам

так яж не настоящий сварщик, а ты хоть выдаешь правильнче ключевые слова для гугления в ответ на мои попытки

вообще оч простое правило - ложить файлы так что бы в коммите все файлы были "рядышком".

потому я репозитории те же рядом с сущностями кладу, ибо мне так удобнее