понял

спасибо

Привет всем.Такой вопрос.Как правильней? При работе с orm сначала создают схему базы и потом её мапят на классы или наоборот : мапят классы и автоматически генерируют базу?

если есть готова бд то второе

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

С автоматической генерацией не надо связываться: крест на миграциях

Отдельно схемы, отдельно модели. Причем для одной таблицы может быть несколько моделей

В идеале должно чекаться соответствие модели схеме. Например, в растовом diesel при компиляции чекается

Господа, день добрый. Вопрос сторонникам DDD. Правильно ли я понимаю, что у Эванса сущность (entity) - это anemic-модель с id? Ну или в реальности, какой-нибудь класс Employer с id, который соответствует id-шнику в базе данных.

Не anemic

Но с id

В идеале должно чекаться соответствие модели схеме. Например, в растовом diesel при компиляции чекается

понял . спасибо

кто-нибудь применяет на практике ddd(domain-driven-design)?

Но с id

Хорошо, но тогда еще вопрос, т.к. есть проблема с этим id Православный вариант репозитория Эванса такой: public interface AccountRepository { void addAccount(Account account); void removeAccount(Account account); void updateAccount(Account account); List query(AccountSpecification specification); } Если лепить без спецификаций (если операций мало, и нет желания усложнять), то это получается DAO. Но в любом случае, у него в метод нужно запихивать уже инициализированную сущность account. Но что делать, если у меня как раз таки есть привязка к id-шникам в базе данных (т.е. изначально я не знаю, какой у сущности id, пока не постучусь в базу)?

Хорошо, но тогда еще вопрос, т.к. есть проблема с этим id Православный вариант репозитория Эванса такой: public interface AccountRepository { void addAccount(Account account); void removeAccount(Account account); void updateAccount(Account account); List query(AccountSpecification specification); } Если лепить без спецификаций (если операций мало, и нет желания усложнять), то это получается DAO. Но в любом случае, у него в метод нужно запихивать уже инициализированную сущность account. Но что делать, если у меня как раз таки есть привязка к id-шникам в базе данных (т.е. изначально я не знаю, какой у сущности id, пока не постучусь в базу)?

1. Без update 2. Сущности не может быть без id

Хорошо, но тогда еще вопрос, т.к. есть проблема с этим id Православный вариант репозитория Эванса такой: public interface AccountRepository { void addAccount(Account account); void removeAccount(Account account); void updateAccount(Account account); List query(AccountSpecification specification); } Если лепить без спецификаций (если операций мало, и нет желания усложнять), то это получается DAO. Но в любом случае, у него в метод нужно запихивать уже инициализированную сущность account. Но что делать, если у меня как раз таки есть привязка к id-шникам в базе данных (т.е. изначально я не знаю, какой у сущности id, пока не постучусь в базу)?

А ты сразу выгребай всё из базы, getAll()

id это поле хранилища данных и ты его не должен трогать, хранилище само будет назначать тебе эти id

А ты сразу выгребай всё из базы, getAll()

Как это, выгребать все из базы?

Получается, я создавая в классе с бизнес-логикой этот account, должен не трогать id?

Ну если тебе зачем то нужен id то как ты узнешь какие у тебя есть, а какие нет, или я не совсем верно понял твой вопрос.

Допустим ты создаёшь новый аккаунт представь аналогию с блокнотом, ты создаёшь новый документ, его пока не существует на диске он называется new doc 1, потом когда ты его сохраняешь, то у него появляется id т.е. его имя на диске, а в случае с базой данных это номер, а не имя. А когда Account ещё не сохранён* то это поле null

Ну если тебе зачем то нужен id то как ты узнешь какие у тебя есть, а какие нет, или я не совсем верно понял твой вопрос.

Вопрос в том, что у Эванса в репозиторий в метод add(Account account) идет уже инициализированный слоем выше объект, и если id - это обязательное свойство сущности, что мне с ним делать в слое выше?

Просто те подходы, которые рассмотрены в примерах в интернете, этот момент не затрагивают - там либо явно задается рандомный uuid, либо еще каким-то способом генерируется id, и случай "есть таблица бд с auto increment primary key" не рассматривается

вообще привязка к каким id? тем что primary key или uuid?

структуры таблиц бд в примерах я не видел,

Вопрос в том, что у Эванса в репозиторий в метод add(Account account) идет уже инициализированный слоем выше объект, и если id - это обязательное свойство сущности, что мне с ним делать в слое выше?

Какое это время в видео?

Какое это время в видео?

конкретно этот пример брал из статьи на хабре

если прям конкретные примеры, которые я смотрел, то вот https://bitbucket.org/sixty-north/d5-kanban-python/src/4f880ea7425a5bf1d859474cbf76897510a58978/infrastructure/persistence_oriented_repos/work_item_repository.py?at=master&fileviewer=file-view-default

и вот еще, там это все как я понял разруливается hibernate-ом, я пока без orm пробую делать в целях понимания https://github.com/citerus/dddsample-core/blob/master/src/main/java/se/citerus/dddsample/infrastructure/persistence/hibernate/CargoRepositoryHibernate.java

Просто те подходы, которые рассмотрены в примерах в интернете, этот момент не затрагивают - там либо явно задается рандомный uuid, либо еще каким-то способом генерируется id, и случай "есть таблица бд с auto increment primary key" не рассматривается

просто оставляешь его приватным и не трогаешь нигде

просто оставляешь его приватным и не трогаешь нигде

А это правильно вообще? Нигде кроме слоя инфраструктуры?

а зачем он вам?

а зачем он вам?

Конкретно в моем случае, у меня есть класс Card (таблица id, text, deck_id)) и класс CardStats(id, card_id, some_numbers). Юзер создает карточку Card, идет запрос к бд, я должен узнать id-шник, чтобы создать объект CardStats и впихнуть туда card_id.

ну и обратный вариант, я иду в класс логики, беру CardStats по нужным мне критериям и, если я правильно сделал, что храню в сущности CardStats id-шник конкретной карты card_id, выгружаю из базы уже конкретные карты по этим id-шникам

беру и сохраняю, соответственно, через репозиторий

Это же умеют сами делать doctrine/hibernate

Это же умеют сами делать doctrine/hibernate

у меня тот случай, когда я должен работать без orm

Тогда зачем вы усложняете?)

Тогда зачем вы усложняете?)

я наоборот пытаюсь понять, как сделать проще и правильнее

с точки зрения ddd

с точки зрения ddd

с точки зрения ddd ты должен загоняться по предметной области, разобраться как оно с точки зрения бизнеса должно работать, разбираться что именно и зачем ты делаешь

а orm или нет - у тебя с точки зрения бизнес логики будет примерно одинаково

то есть если у тебя нет orm - она у тебя появится

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

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

если SOLID не идет - попробуй GRASP

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

SOLID просто больше оринтирован на рефакторинг и анализ потока изменений

скоро доберусь)) дядя боб просто много текста пишет заумного.

ну тогда Лармана точно не осилишь)

наоборот ж

дядя Боб все упрощает и немного искажает, чтобы легко донести мысли

если у тебя к примеру не практикуется регулярный рефакторинг, ты не думаешь как используется то что ты пишешь - SOLID не для тебя.

скоро доберусь)) дядя боб просто много текста пишет заумного.

они всю юзают заумные слова :(

ну просто он реально некоторые простые вещи сложно расписывает

ну просто он реально некоторые простые вещи сложно расписывает

приведи пример

лисков

LSP

конкретнее

что именно по твоему сложно расписывается?

ERROR: S client not available

Если что )

lsp - допустим есть тип Птица и есть подтипы: орёл, цапля, воробей. Все птицы умеют летать и во всех местах программы вместо птицы можно будет подставить три эти реализации и всё будет работать. Substitutability is a principle in object-oriented programming stating that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e. an object of type T may be substituted with any object of a subtype S) without altering any of the desirable properties of T (correctness, task performed, etc.). More formally, the Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called (strong) behavioral subtyping, Но есть ещё пингвин, который летать не умеет но он ЯВЛЯЕТСЯ птицей, добавляем пингвина в нашу программу и опять говорим всем птицам лететь, все выполняют команду, пингвин бросает UnsupportedOperationException. Или пингвин должен летать, т.к. он ЯВЛЯЕТСЯ птицей или он не должен быть птицей. Пингвин это нарушение lsp, пример из реального мира: java collection framework.

первый пример годный, а второй трындец. в книге все есть

хз, проще чем у боба про SOLID ничего нет. Если что предлагаю просто то что ты прочитал у Боба шлифануть видяшками

(его же лекции + вот мне нравится у этого челика: https://www.youtube.com/watch?v=bVwZquRH1Vk

http://blog.byndyu.ru/2009/10/solid.html вот здесь еще норм

Если каждому объекту типа O1 типа S соответствует объект O2 типа T. Таким образом, всех програм P, определенных на основе T, поведение P не меняется при замене O1 на O2, причем S является подтипом T.

это вырезка из книги

(его же лекции + вот мне нравится у этого челика: https://www.youtube.com/watch?v=bVwZquRH1Vk

топовый тип

Если каждому объекту типа O1 типа S соответствует объект O2 типа T. Таким образом, всех програм P, определенных на основе T, поведение P не меняется при замене O1 на O2, причем S является подтипом T.

это оригинальное определение

почти все видосы посмотрел

ага

ага

ну то есть а что ты еще хочешь? Что бы он не приводил в книге оригинальное определение? он же потом далее другими словами объясняет

хочется чтоб вообще просто было ))

ну то есть а что ты еще хочешь? Что бы он не приводил в книге оригинальное определение? он же потом далее другими словами объясняет

мне оч понравилось через логику Хоара)

что б не читать неделю

хочется чтоб вообще просто было ))

LSP это когда у тебя система завязана на одну ху*ню, а ты вместо нее "подставляешь" другую ху*ню, и поведение системы от этого не меняется

та я знаю))

LSP это когда у тебя система завязана на одну ху*ню, а ты вместо нее "подставляешь" другую ху*ню, и поведение системы от этого не меняется

не сильно меняется*

не сильно меняется*

не меняется совсем.

хм

оно не должно меняться

хм

поведение, оно не учитывает детали реализации вроде "ну тип теперь оно не в файл пишет а в базу"

поведение, оно не учитывает детали реализации вроде "ну тип теперь оно не в файл пишет а в базу"

но учитывает, что не вылетит новый exception

но учитывает, что не вылетит новый exception

ну если вылетит - ты нарушил контракт)

ну я про это и говорю)

не сильно меняется*

суть именно в том что бы подстановка другой реализации какой-либо херни вообще никак не влияла на систему. Контракты как были так и остались. Все прекондишены как были так и остались. Все инварианты должны остаться прежними...

суть именно в том что бы подстановка другой реализации какой-либо херни вообще никак не влияла на систему. Контракты как были так и остались. Все прекондишены как были так и остались. Все инварианты должны остаться прежними...

я понял