ну это root атрибут. очевидно что при этом просто не будет productRepository тогда

ProductRepository )

скажи это бизнесу "мы ложим ваш продук в репозиторий продуктов". А они такие "Вы хотели сказать на склад?"

в c# префикс I - это изза упрощенной записи. class Something: BaseClass, IImplementedInterface1, IImplementedInterface2 {

Catalog->add(Product)

мм. лучше репозиторий. так ясно понятно, что это инфраструктура. А каталог и бук - это можно и за сущности принять..

а какая собственно разница?)))

чтобы различать интерфейсы и базовый класс

ProductRepository->getAllProducts()

ты не думаешь что это симптом проблемы что тебе не понятно что делают классы и какова их зона ответственности без суффиксов/префиксов?)

чтобы различать интерфейсы и базовый класс

ээээм.... у тебя если есть интерфейс значит ты можешь сказать что особенного в классе что бы небыло коллизий. Если не можешь - тебе не нужен интерфейс.

вопрос сохраняется ли семантика. Этот суффикс часто добавляют по дефолту. Хотя ошибки в духе InvalidTransaction вполне себе описыватю что это такое.

потому что это как бы сущность из предметной области (может я ошибаюсь) но аналогия вроде если есть плохая практика использовать окончиная er or т.е. это поведение которое должно быть в классе то при моделировании реального принтера или роли были бы такие классы как Printer и Manager как абстракции и это было бы исключением этого правила, т.е. они являются сущностями.

в c# префикс I - это изза упрощенной записи. class Something: BaseClass, IImplementedInterface1, IImplementedInterface2 {

а если его убрать все сломается к чертям?)

потому что это как бы сущность из предметной области (может я ошибаюсь) но аналогия вроде если есть плохая практика использовать окончиная er or т.е. это поведение которое должно быть в классе то при моделировании реального принтера или роли были бы такие классы как Printer и Manager как абстракции и это было бы исключением этого правила, т.е. они являются сущностями.

это не может быть просто объект?

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

ну да, Catalog это интерфейс который может имплементить какой-нибудь HIbernateProductRepository

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

они не нужны

а как вышло что они там есть - это да, известно

в c# префикс I - это изза упрощенной записи. class Something: BaseClass, IImplementedInterface1, IImplementedInterface2 {

потому что это как бы сущность из предметной области (может я ошибаюсь) но аналогия вроде если есть плохая практика использовать окончиная er or т.е. это поведение которое должно быть в классе то при моделировании реального принтера или роли были бы такие классы как Printer и Manager как абстракции и это было бы исключением этого правила, т.е. они являются сущностями.

зачем делить все на сущности и не сущность?)

в c# префикс I - это изза упрощенной записи. class Something: BaseClass, IImplementedInterface1, IImplementedInterface2 {

это не объясняет почему и зачем

зачем делить все на домен и недомен? :)

зачем делить все на домен и недомен? :)

затем что там четко прослеживается разделение. Давай так, чем отличается сущность от VO?

идентификатором

у тебя может быть класс Money. В контексте монетного двора это будет сущность а в контексте магазина - VO

угу

следовательно без указания контекста нет смысла рассуждать или делать различия "сущность/не сущность"

с сервисами та же история - у тебя есть некий "каталог" товаров, как он реализован - плевать. Сущность это или сервис - плевтаь.

из контекста будет понятно что это корень агрегата или просто репозиторий.

просто экторы

все есть "какие-то штуки"

так ладно пойду работать(

просто экторы

оно? https://ru.wikipedia.org/w/index.php?title=%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%B0%D0%BA%D1%82%D0%BE%D1%80%D0%BE%D0%B2&stable=1

угу

GuestRepository или GuestBook?)

pureFabrication и нормальный обьект

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

угу

что то с паралельными вычеслениями как то не совсем в тему ну ладно, посмотрим

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

для связки тех обьектов которые являются частью модели ( только если их нельзя связать не нарушив какой нибудь принцип) что то вроде клея но его должно быть как можно меньше. Идеальный варинат как я понимаю это есть какая то предметная область, мы перенесли все обьекты реального мира в модель и всё.

что то с паралельными вычеслениями как то не совсем в тему ну ладно, посмотрим

вот я тоже читаю... я когда про actor model читал там ничего про паралельные вычисления небыло

http://wiki.c2.com/?ActorsModel

Наброшу насчет переноса реального мира в модели: http://udidahan.com/2012/03/05/dont-try-to-model-the-real-world-it-doesnt-exist/

Для меня лично проблема такого переноса чаще всего сводиться даже не к "нематериальным" сущностям, а к тому что бизнес не до конца сам понимает какими объектами оперирует.

Ну тут уж Event Storming должен помочь.

Кстати, у кого-нибудь есть положительный опыт по Event Storming? Делитесь!

Кстати, у кого-нибудь есть положительный опыт по Event Storming? Делитесь!

наши БА не знают что это такое(

в целом я плохо представляю как подобное делать не имея возможности собрать в одном помещении всех представителей бизнеса необходимых + кого-то со стороны команды

и что делать в такой ситуации

Чуть ли не в каждом докладе по DDD говорят о том, что делать DDD без тесного взаимодействия команды невозможно. И под тесным как раз понимается собрать в одном помещении

Чуть ли не в каждом докладе по DDD говорят о том, что делать DDD без тесного взаимодействия команды невозможно. И под тесным как раз понимается собрать в одном помещении

тут проблемы вытянуть всех людей на кол, не то что вместе собрать

Чуть ли не в каждом докладе по DDD говорят о том, что делать DDD без тесного взаимодействия команды невозможно. И под тесным как раз понимается собрать в одном помещении

под тесным понимают общаться, а не посидеть друг на против друга и потупить)

у нас как-то был проектик где система затрагивала где-то 5 разных отделов очень большой компании и эти отделы в разных городах сидели

под тесным понимают общаться, а не посидеть друг на против друга и потупить)

ну с event storming никто не тупит

еще момнт - event storming в теории помогает решать вопросы только с существующим бизнесом. Если ты автоматизируешь процесс существующий

если ты пилишь что-то относительно новое и у тебя нет никакой инфы - ты проигрываешь чуть чуть

Кстати, хорошее замечание

а еще есть всякие Impact mapping

если ты пилишь что-то относительно новое и у тебя нет никакой инфы - ты проигрываешь чуть чуть

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

как раз таки для "новых штук" и "непонятно как лучше" должно хорошо работать

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

именно по этому важно как можно быстрее выйти в прод (или хотя бы бэту)

относительно новое это считай, что у тебя нет доступа к специалисту предметной области

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

один проект так 3 года эпизодически пилили

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

ну тут есть разница на самом деле

если это уже “продали”, то как бы ок, надо сделать

если это “бляяя, мы не продадИМ”, то эт хуйня скорее всего

у нас продажи работают быстрее нас))

если это “бляяя, мы не продадИМ”, то эт хуйня скорее всего

у нас с Сэйлами большая война была, на тему "хватит пихать в контракт фичалисты"

но их тоже понимать надо - продать "неизвестно что неизвестно когда" крайне сложно

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

сделать “неизвестно что неизвестно когда” тоже не так и просто

и бизнесу намного спокойнее найти индусам которые выставят весьма простой контрак и скинут риски с бизнеса на самих себя)

сделать “неизвестно что неизвестно когда” тоже не так и просто

Можем, практикуем :)

понятное дело, что можем)

ну это ж работает не "неизвестно когда", ты выставляешь ограничения

скажем "давайте так, вот что бы вам за 2 недели сделать?" что бы приоритеты выяснить

кто чем пользуется для uml моделирования? хочу сменить инструмент, надоел

кто чем пользуется для uml моделирования? хочу сменить инструмент, надоел

umlet или umletino ( если не ошибаюсь) онлайн версия. Можно сказать что то вроде блокнота в винде где ничего лишнего, в то время как другие редакторы это уже уровень Ворда

спасибо, сейчас посмотрим

а я в draw-io накидываю...

ну и еще нравятся сервисы где можно DSL-ем накидывать

https://yuml.me/

посмотрел umlet, слабоват, нужно больше возможностей

посмотрел umlet, слабоват, нужно больше возможностей

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

Все понемногу, и структурные, а поведенческие, и схемы деплоя и инфраструктуры

draw.io прям красота, то что искал! спасибо!

посмотрел umlet, слабоват, нужно больше возможностей

а там много возможностей, там можно и сиквенс диаграммы и стейт и много чего ещё. Там по разделам уже готовые фигурки почти под всё есть

draw.io прям красота, то что искал! спасибо!

StarUML есть еще, в виде прилаги все же иногда удобнее иметь

StarUML есть еще, в виде прилаги все же иногда удобнее иметь

вот я им и пользовался, снес нафиг, draw.io просто прекрасен

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

автовыравнивание связей - после пиксель дроча в staruml это просто манна небесная)

кто-то еще пользуетяс десктопными приложениями для подобного? интересненько

ага, он еще и в облако сразу сохраняет все)

спасибо еще раз