DK
Это архитектура приложения, но не DDD
Берем простую Layer Arch, какой подход наиболее адекватен для построения доменной модели в ней 1 или 2? Или есть какой-то более хороший вариант(не CRUD)?
Size: a a a
2020 September 26
SM
Если мы говорим о контроле сложности кода приложения по крайней мере
Там вроде график зависимости трудозатрат на разработку, а не график сложности. Понятие сложности неформализовано ещё.
DE
Смотрю, читаю. Возник вопрос. Написал свое видение, интересно альтернативное мнение.
Возьмите более сложную предметную область вроде разобранной здесь и тренируйтесь в анализе подобластей. А не просто с одним списком.
SM
Видимо нужен новый термин: «архитектура из книг DDD”
Потому что явно не хватает слова для обозначения того, что называют этими буквами :)
Потому что явно не хватает слова для обозначения того, что называют этими буквами :)
Domain centric architecture style
DK
Возьмите более сложную предметную область вроде разобранной здесь и тренируйтесь в анализе подобластей. А не просто с одним списком.
Но моя проблема конкретна и достаточно проста. 2 разных списка и опциональные папки к ним.
Как это все напихать в кучу я знаю(пойти от SOA или MDA), а как сделать это красиво и по DDD c Layer Architecture нет.
Как это все напихать в кучу я знаю(пойти от SOA или MDA), а как сделать это красиво и по DDD c Layer Architecture нет.
SM
Да никто не скажет как, так как никто не знает что там у тебя за логика.
SM
Это как спросить как мне заработать много денег
DK
Да никто не скажет как, так как никто не знает что там у тебя за логика.
логика TodoList + папки, только папки как дополнительный модуль, который можно применить или отключить.
SM
Это статичное описание какой-то структуры. А что за бизнес процессы у вас происходят.
A
Смотрю, читаю. Возник вопрос. Написал свое видение, интересно альтернативное мнение.
Хз как правильно будет для вас, для практического "правильно" нужны практические кейсы и анализ цепочек вызовов.
Но если просто альтернативное мнение, то вот например:
https://github.com/ivanpaulovich/ddd-tdd-rich-domain-model-dojo-kata
Но если просто альтернативное мнение, то вот например:
https://github.com/ivanpaulovich/ddd-tdd-rich-domain-model-dojo-kata
SM
Кто участвует в них. Что за события происходят и т.д.
JS
логика TodoList + папки, только папки как дополнительный модуль, который можно применить или отключить.
то есть папки всегда есть в архитектуре, но не всегда отображаются пользователю?
DK
то есть папки всегда есть в архитектуре, но не всегда отображаются пользователю?
если совсем просто, то так
если посложнее, то как совсем отдельная полностью выпиливаемая фича или с минимальными связями.
если посложнее, то как совсем отдельная полностью выпиливаемая фича или с минимальными связями.
DK
то есть папки всегда есть в архитектуре, но не всегда отображаются пользователю?
примеров clean + ToDo + папки много, но там все жестко завязано в сам список.
JS
отсутствие папки считать корневой папкой, например. а присутствие игнорировать. тогда папки смогут быть и не быть одновременно
JS
только боюсь, это не связано с DDD
DE
Но моя проблема конкретна и достаточно проста. 2 разных списка и опциональные папки к ним.
Как это все напихать в кучу я знаю(пойти от SOA или MDA), а как сделать это красиво и по DDD c Layer Architecture нет.
Как это все напихать в кучу я знаю(пойти от SOA или MDA), а как сделать это красиво и по DDD c Layer Architecture нет.
Раз ваша проблема достаточно проста, то ей и не нужна архитектура для организации сложных проектов.
DE
Но моя проблема конкретна и достаточно проста. 2 разных списка и опциональные папки к ним.
Как это все напихать в кучу я знаю(пойти от SOA или MDA), а как сделать это красиво и по DDD c Layer Architecture нет.
Как это все напихать в кучу я знаю(пойти от SOA или MDA), а как сделать это красиво и по DDD c Layer Architecture нет.
Так как у вас будет всего 1 контекст с 2 сущностями с 4 полями и с 0 методов.
A
отсутствие папки считать корневой папкой, например. а присутствие игнорировать. тогда папки смогут быть и не быть одновременно
Папка Шрёдингера)
DK
только боюсь, это не связано с DDD
а теперь к DDD
Домен это функциональная модель, т.е. Если есть список, значит это его элементы + добавление, удаление, редактирование. При этом описанное в терминах бизнеса.
Если возникает другой список, например, с картинками значит ли это, что мне надо создавать вторую доменную модель? Или возможно ограничиться выделением абстрактного списка и двумя его потомками типами?
Домен это функциональная модель, т.е. Если есть список, значит это его элементы + добавление, удаление, редактирование. При этом описанное в терминах бизнеса.
Если возникает другой список, например, с картинками значит ли это, что мне надо создавать вторую доменную модель? Или возможно ограничиться выделением абстрактного списка и двумя его потомками типами?
AbstractToDo -> [TextToDo, PictureToDo]