Re[12]: ддд с чего начать
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.02.16 13:56
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:


S>>>Ну, если совсем грубо: В DDD предлагается шлёпать сущности не абы как, а отражая реалии предметной области (см в предыдущем посте пример с сотрудником), вот и всё.

G>>А в не-DDD как предлагается делать?

S>Да то же самое по большому счёту. Ну, если не перебарщивать с акын-стайл методиками (aka что вижу, то и пишу).

S>Вся разница — в DDD расписаны базовые принципы, в остальных — всё на откуп аналитику/архитектору.
Где именно в DDD они расписаны? В книге эванса про анализ почти ничего нет. Все остальное — додумки, которые иногда противоречат друг другу.
Re[13]: ддд с чего начать
От: Baudolino  
Дата: 20.02.16 14:07
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Где именно в DDD они расписаны? В книге эванса про анализ почти ничего нет. Все остальное — додумки, которые иногда противоречат друг другу.

Я предлагаю всё-таки не считать, что у Эванса монополия на термин DDD.

Не-DDD подходы кстати хорошо известны. Например solution-driven design: у нас есть вордпресс/хибернейт/сап, давайте его натянем на задачу, которая решается в три строчки более подходящим инструментом или архитектурой.
Re[14]: ддд с чего начать
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.02.16 14:14
Оценка:
Здравствуйте, Baudolino, Вы писали:

B>Здравствуйте, gandjustas, Вы писали:


G>>Где именно в DDD они расписаны? В книге эванса про анализ почти ничего нет. Все остальное — додумки, которые иногда противоречат друг другу.

B>Я предлагаю всё-таки не считать, что у Эванса монополия на термин DDD.
А есть другой источник? Не отдельные посты в блогах апологетов, а именно цельное описание.

B>Не-DDD подходы кстати хорошо известны. Например solution-driven design: у нас есть вордпресс/хибернейт/сап, давайте его натянем на задачу, которая решается в три строчки более подходящим инструментом или архитектурой.

Если исключить из рассмотрения наличие "более подходящих" инструментов, то какой еще подход существует кроме "отражать реалии предметной области" ?
Re[15]: ддд с чего начать
От: Baudolino  
Дата: 20.02.16 14:37
Оценка:
Здравствуйте, gandjustas, Вы писали:

B>>Я предлагаю всё-таки не считать, что у Эванса монополия на термин DDD.

G>А есть другой источник? Не отдельные посты в блогах апологетов, а именно цельное описание.
Не уверен. Давно не видел хороших и актуальных книг по архитектуре, даже на английском.

G>Если исключить из рассмотрения наличие "более подходящих" инструментов, то какой еще подход существует кроме "отражать реалии предметной области" ?

Я не думаю, что SDD нужно исключать из рассмотрения — этот подход применяется в огромном количестве проектов и команд в той или иной степени. Имеющиеся решения подгоняются под задачу, будь это на уровне интерфейса (тулбары с непонятными и бессмысленными обозначениями, формы, которых требуется ввести всё, безумные ограничения на вид пароля вместо двухфакторной аутентификации и т.п.) и бизнес-логики (например, антипаттерны singleton и table data gateway, жутко дорогие в поддержке).
Re[16]: ддд с чего начать
От: sourcerer Германия  
Дата: 20.02.16 15:07
Оценка: 37 (2)
Здравствуйте, 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).
Недостатки прощаются, достоинства — никогда.
Отредактировано 20.02.2016 15:10 sourcerer . Предыдущая версия .
Re[17]: ддд с чего начать
От: okon  
Дата: 20.02.16 16:03
Оценка: +1
Здравствуйте, sourcerer, Вы писали:


S>Вторая конечно не DDD — более техническая, но реактивный подход мне очень нравится


Попался !
Рассказывай про реактивный подход ...
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Re[18]: ддд с чего начать
От: sourcerer Германия  
Дата: 20.02.16 16:26
Оценка:
Здравствуйте, okon, Вы писали:

O>Здравствуйте, sourcerer, Вы писали:



S>>Вторая конечно не DDD — более техническая, но реактивный подход мне очень нравится


O>Попался !

O>Рассказывай про реактивный подход ...

Собственно, это чисто технический подход — никто не запрещает его и в DDD применять.
В этой конкретной книге идет описание применения реактивного програмирования во фреймвёрке AKKA (есть его форк для .NET — AKKA.Net).

А знакомство с самим подходом в контексте .NET нужно начинать ИМХО вот с этих книжек
(может статься, что только их и будет достаточно — никакие фреймвёрки больше не понадобятся):

1. Reactive Extensions in Action with examples in C#
2. Reactive Design Patterns
Недостатки прощаются, достоинства — никогда.
Re[19]: ддд с чего начать
От: okon  
Дата: 21.02.16 23:40
Оценка:
S>Собственно, это чисто технический подход — никто не запрещает его и в DDD применять.
S>В этой конкретной книге идет описание применения реактивного програмирования во фреймвёрке AKKA (есть его форк для .NET — AKKA.Net).

А почему Акка а не ReactiveExtensions от МС ?
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Re[18]: ддд с чего начать
От: LeonidV Ниоткуда http://vygovskiy.com
Дата: 28.03.16 10:29
Оценка:
Здравствуйте, 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, там немного по другому.
http://jvmmemory.com — простой способ настройки JVM
Re: ддд с чего начать
От: Vladek Россия Github
Дата: 29.03.16 16:15
Оценка: 1 (1)
Здравствуйте, okon, Вы писали:

O>Может есть ддд описание где расжевывается не то как он устроен, а зачем он так устроен.


По сути, это обычный ООП, просто указаны абстракции, которые могут встретиться во многих задачах. Другими словами, Эрик Эванс занимался ООП и со временем выделил из законченных проектов набор универсальных абстракций, которые и описал в своей книге.

Тут
Автор: Vladek
Дата: 02.10.15
уже писал:

Само DDD лично мне легче было понять на примере устройства типичного текстового редактора. Агрегат — это документ, его содержимое — это набор правок. Применяя правки к документу, мы меняем его состояние: можем откатиться назад, можем накатить правку несколько раз. Правка содержит объекты-значения, например символы, которые пользователь вводил с клавиатуры, редактируя документ. Сущность — текущее состояние документа, например копия текста; отдельная правка в документе. Сервисы — это, например, служба проверки правописания; подсчёт слов в документе.

Re: ддд с чего начать
От: Qulac Россия  
Дата: 29.03.16 17:33
Оценка:
Здравствуйте, 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 по сути вы получаете то же самое.
Программа – это мысли спрессованные в код
Re[2]: ддд с чего начать
От: Sinix  
Дата: 29.03.16 18:51
Оценка:
Здравствуйте, Vladek, Вы писали:

V>По сути, это обычный ООП, просто указаны абстракции, которые могут встретиться во многих задачах. Другими словами, Эрик Эванс занимался ООП и со временем выделил из законченных проектов набор универсальных абстракций, которые и описал в своей книге.


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

Вот вы похоже первую половину пропустили
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.