Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>Ну, если совсем грубо: В DDD предлагается шлёпать сущности не абы как, а отражая реалии предметной области (см в предыдущем посте пример с сотрудником), вот и всё. G>>А в не-DDD как предлагается делать?
S>Да то же самое по большому счёту. Ну, если не перебарщивать с акын-стайл методиками (aka что вижу, то и пишу). S>Вся разница — в DDD расписаны базовые принципы, в остальных — всё на откуп аналитику/архитектору.
Где именно в DDD они расписаны? В книге эванса про анализ почти ничего нет. Все остальное — додумки, которые иногда противоречат друг другу.
Здравствуйте, gandjustas, Вы писали:
G>Где именно в DDD они расписаны? В книге эванса про анализ почти ничего нет. Все остальное — додумки, которые иногда противоречат друг другу.
Я предлагаю всё-таки не считать, что у Эванса монополия на термин DDD.
Не-DDD подходы кстати хорошо известны. Например solution-driven design: у нас есть вордпресс/хибернейт/сап, давайте его натянем на задачу, которая решается в три строчки более подходящим инструментом или архитектурой.
Здравствуйте, Baudolino, Вы писали:
B>Здравствуйте, gandjustas, Вы писали:
G>>Где именно в DDD они расписаны? В книге эванса про анализ почти ничего нет. Все остальное — додумки, которые иногда противоречат друг другу. B>Я предлагаю всё-таки не считать, что у Эванса монополия на термин DDD.
А есть другой источник? Не отдельные посты в блогах апологетов, а именно цельное описание.
B>Не-DDD подходы кстати хорошо известны. Например solution-driven design: у нас есть вордпресс/хибернейт/сап, давайте его натянем на задачу, которая решается в три строчки более подходящим инструментом или архитектурой.
Если исключить из рассмотрения наличие "более подходящих" инструментов, то какой еще подход существует кроме "отражать реалии предметной области" ?
Здравствуйте, gandjustas, Вы писали:
B>>Я предлагаю всё-таки не считать, что у Эванса монополия на термин DDD. G>А есть другой источник? Не отдельные посты в блогах апологетов, а именно цельное описание.
Не уверен. Давно не видел хороших и актуальных книг по архитектуре, даже на английском.
G>Если исключить из рассмотрения наличие "более подходящих" инструментов, то какой еще подход существует кроме "отражать реалии предметной области" ?
Я не думаю, что SDD нужно исключать из рассмотрения — этот подход применяется в огромном количестве проектов и команд в той или иной степени. Имеющиеся решения подгоняются под задачу, будь это на уровне интерфейса (тулбары с непонятными и бессмысленными обозначениями, формы, которых требуется ввести всё, безумные ограничения на вид пароля вместо двухфакторной аутентификации и т.п.) и бизнес-логики (например, антипаттерны singleton и table data gateway, жутко дорогие в поддержке).
Здравствуйте, Baudolino, Вы писали:
B>Здравствуйте, gandjustas, Вы писали:
B>>>Я предлагаю всё-таки не считать, что у Эванса монополия на термин DDD. G>>А есть другой источник? Не отдельные посты в блогах апологетов, а именно цельное описание. B>Не уверен. Давно не видел хороших и актуальных книг по архитектуре, даже на английском.
Хм, странно... а по-моему книжек вполне достаточно и именно сейчас, требуется "лишь" время на чтение-осознание-применение.
Здесь я имею ввиду книжки автора Vaughn Vernon (причем ОБЕ последних) — Эванс ОЧЕНь сильно устарел:
1. Implementing Domain-Driven Design
2. Reactive Messaging Patterns with the Actor model
Вторая конечно не DDD — более техническая, но реактивный подход мне очень нравится
Также сейчас появились статьи по Onion Architecture (сужу по немецкоязычному журналу dotnetpro).
S>Вторая конечно не DDD — более техническая, но реактивный подход мне очень нравится
Попался !
Рассказывай про реактивный подход ...
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
O>Здравствуйте, sourcerer, Вы писали:
S>>Вторая конечно не DDD — более техническая, но реактивный подход мне очень нравится
O>Попался ! O>Рассказывай про реактивный подход ...
Собственно, это чисто технический подход — никто не запрещает его и в DDD применять.
В этой конкретной книге идет описание применения реактивного програмирования во фреймвёрке AKKA (есть его форк для .NET — AKKA.Net).
А знакомство с самим подходом в контексте .NET нужно начинать ИМХО вот с этих книжек
(может статься, что только их и будет достаточно — никакие фреймвёрки больше не понадобятся):
S>Собственно, это чисто технический подход — никто не запрещает его и в DDD применять. S>В этой конкретной книге идет описание применения реактивного програмирования во фреймвёрке AKKA (есть его форк для .NET — AKKA.Net).
А почему Акка а не ReactiveExtensions от МС ?
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
O>Здравствуйте, sourcerer, Вы писали:
S>>Вторая конечно не DDD — более техническая, но реактивный подход мне очень нравится
O>Попался ! O>Рассказывай про реактивный подход ...
Я пока сильно в него не углубился, но сейчас рассматриваю его так. Делать объединение данных в самой крайней точке, где это возможно (это особенно актуально для микросервисной архитектуре). Например, нам надо список активных задач работнику. Это можно сделать классической схемой в рамках одного HTTP-запроса:
UI -> Facade microservice
-> Tasks Microservice
-> DB
<- DB
<- (200) Tasks Microservice
UI <- (200) Facade microservice
Здесь UI открывает HTTP-соединение с Facade microservice, который в свою очередь открывается соединение с Tasks Microservice. TaskMicroservice делает запрос в БД и отвечает фасаду, который отвечет UI.
Таким образом:
1. Каждый сервис должен сохранить в своей памяти все задачи, которые запросил UI.
2. Мы имеем два длительных HTTP-соединения.
А можно так (здесь потребуется push-уведомления UI)
UI -> Faced microservices
UI <- 202 (async) | // запрос корректен и будет обработан ассинхронно
| -> Tasks Microservice
<- 202 (async) | -> DB
| <- DB // выгрузку делаем по задачам, не дожидаясь получения всей выборки
| -> UI push notifier
|
|
UI <-------------------------------------------------------|
Получаем:
1. HTTP-соединения открываются на минимально возможное время
2. Только в одной точке (UI) собираем все необходимые задач, расход на оперативку минимален.
3. Можно легко вставить очередь между всеми компонентами.
Из минусов — гораздо сложнее программировать, нужен еще один сервис push-уведомлений клиента.
Это про архитектурный подход и его моё понимание. Еще реактивное программирование применяют к UI, там немного по другому.
Здравствуйте, okon, Вы писали:
O>Может есть ддд описание где расжевывается не то как он устроен, а зачем он так устроен.
По сути, это обычный ООП, просто указаны абстракции, которые могут встретиться во многих задачах. Другими словами, Эрик Эванс занимался ООП и со временем выделил из законченных проектов набор универсальных абстракций, которые и описал в своей книге.
Само DDD лично мне легче было понять на примере устройства типичного текстового редактора. Агрегат — это документ, его содержимое — это набор правок. Применяя правки к документу, мы меняем его состояние: можем откатиться назад, можем накатить правку несколько раз. Правка содержит объекты-значения, например символы, которые пользователь вводил с клавиатуры, редактируя документ. Сущность — текущее состояние документа, например копия текста; отдельная правка в документе. Сервисы — это, например, служба проверки правописания; подсчёт слов в документе.
Здравствуйте, okon, Вы писали:
O>очень как-то сложно описывается, O>например если посмотреть ту же вики то выделяются следующие элементы O>Элементы DDD O>3.1 Контекст O>3.2 Сущность O>3.3 Объект-значение O>3.4 Сводный корень O>3.5 Службы
O>Совсем не понятно зачем так раздроблено, чем плохо делать как обычно — модель данных, бизнес модель и рычажки методы для управления бизнес моделью. Вроде получаем те же плюшки в итоге — язык бизнес функций, я так понимаю основная затея ддд чтобы верхний уровень хорошо коррелировал с бизнес-требованиями.
O>Может есть ддд описание где расжевывается не то как он устроен, а зачем он так устроен.
Это обычный ООП подход к разработке. Эванс в книге правда еще свою философию под это подвел. Поэтому если вы используете ООП и right domain model по сути вы получаете то же самое.
Здравствуйте, Vladek, Вы писали:
V>По сути, это обычный ООП, просто указаны абстракции, которые могут встретиться во многих задачах. Другими словами, Эрик Эванс занимался ООП и со временем выделил из законченных проектов набор универсальных абстракций, которые и описал в своей книге.
книжка маленькая и читать стоит только первую часть, про "что такое DDD", а не вторую где на сам DDD забивают и начинают натягивать книгу на явапаттерны.