G>А solid и гоф ты уже освоил? И базовую многопоточность.

Сказать "освоил", будет самонадеянно.
Знаю о чём речь,
могу оценить код исходя из этих концепций
и использовать как пищу для размышлений при проектировании.
Многопоточность использую.

Здравствуйте, igor-booch, Вы писали:

G>>А solid и гоф ты уже освоил? И базовую многопоточность.

IB>Сказать "освоил", будет самонадеянно.
IB>Знаю о чём речь,
IB>могу оценить код исходя из этих концепций
IB>и использовать как пищу для размышлений при проектировании.
IB>Многопоточность использую.

Гуд, т.к. эти вещи являются базов для дальнейшего продвижения. Реактивщина построена на понимании базовой многопоточности, блокировок, блокирующих и неблокирующих структур и т.д.

G>В реактивщине могут использоваться как Rich, так и Anemic модели предметной области.
G>Связи между реактивщиной и rich/anemic моделями нет.

Я тоже связи не вижу, тогда не понятно в связи с чем Вы написали
G>>>Кстати, реактивщина и DDD сейчас входят в моду, поэтому некоторые старые энтерпрайзные шаблоны, особенно с анемичной моделью, теряют актуальность.

Про анемичную модель только в связи с DDD упомянули?

Здравствуйте, igor-booch, Вы писали:

G>>В реактивщине могут использоваться как Rich, так и Anemic модели предметной области.
G>>Связи между реактивщиной и rich/anemic моделями нет.

IB>Я тоже связи не вижу, тогда не понятно в связи с чем Вы написали

Я имею ввиду, что тебе надо изучать и anemic/Rich+DDD, и реактивность, это перпендикулярные вещи, но и то и другое нужно изучать для разработки современных корпоративных систем.

G>>>>Кстати, реактивщина и DDD сейчас входят в моду, поэтому некоторые старые энтерпрайзные шаблоны, особенно с анемичной моделью, теряют актуальность.

IB>Про анемичную модель только в связи с DDD упомянули?

Да, rich-модель в DDD противопоставляется anemic-модели.

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

IB>>Больше дотнет, а лучше без привязки к языку или фреймворкам, что-то типа Чистой архитектуры.
IB>>Книга может называться, например так "100 распространённых ошибок проектирования"

G>По дотнету не подсажу, я по джаве работаю в основном.
G>Кстати, реактивщина и DDD сейчас входят в моду, поэтому некоторые старые энтерпрайзные шаблоны, особенно с анемичной моделью, теряют актуальность.
G>Так что я бы посоветовал сразу изучать реактивщину. Она кстати основана на гофовских шаблонах, так что и гоф не помешает изучить/освежить.

А я бы не советовал изучать реактивщину в Java. В Java в обозримом будущем появятся легковесные потоки, что сделает всю реактивщину бесполезным расходом ментальной энергии.

Не знаю, что надо изучать, но лично моё имхо, Фаулера, "дядю Боба" в особенности, паттерны — изучать НЕ надо. А применять тем более.

Я бы хотел почитать книги, написанные теми, кто спроектировал гугл, например. Или амазон. Они тоже, на самом деле, будут оторваны от реальности, но их хотя бы будет писать реально умный дядька. А все эти Фаулеры и дяди Бобы — обычные консультанты, которые что-то там себе придумали и умудрились нагадить в мозги половине мира.

Здравствуйте, igor-booch, Вы писали:

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

http://highscalability.com/blog/category/architecture
http://aosabook.org/en/index.html

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

IB>>>Больше дотнет, а лучше без привязки к языку или фреймворкам, что-то типа Чистой архитектуры.
IB>>>Книга может называться, например так "100 распространённых ошибок проектирования"

G>>По дотнету не подсажу, я по джаве работаю в основном.
G>>Кстати, реактивщина и DDD сейчас входят в моду, поэтому некоторые старые энтерпрайзные шаблоны, особенно с анемичной моделью, теряют актуальность.
G>>Так что я бы посоветовал сразу изучать реактивщину. Она кстати основана на гофовских шаблонах, так что и гоф не помешает изучить/освежить.

vsb>А я бы не советовал изучать реактивщину в Java. В Java в обозримом будущем появятся легковесные потоки, что сделает всю реактивщину бесполезным расходом ментальной энергии.

Реактивщина — это же более высокоуровневые вещи, начиная от манифеста и требований к такой системе, и заканчивая интерфейсами. А реализации могут быть разные, в том числе легкопоточные.
Т.е. реактивщина — это философия. А ты говоришь про низкоуровневую реализацию. Ну появятся легковесные потоки, тебе же всё равно нужны будут архитектурные паттерны. Реактивщина их и предоставляет.
Реактивщина дает конкретные ответы на многие вопросы, на которые просто "легковесные" потоки ответа не дают. Например, как построить устойчивую под нагрузкой систему.

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

G>Реактивщина — это же более высокоуровневые вещи, начиная от манифеста и требований к такой системе, и заканчивая интерфейсами. А реализации могут быть разные, в том числе легкопоточные.
G>Т.е. реактивщина — это философия. А ты говоришь про низкоуровневую реализацию. Ну появятся легковесные потоки, тебе же всё равно нужны будут архитектурные паттерны. Реактивщина их и предоставляет.
G>Реактивщина дает конкретные ответы на многие вопросы, на которые просто "легковесные" потоки ответа не дают. Например, как построить устойчивую под нагрузкой систему.

Реактивщина это reactive-streams, project reactor, Spring Webflux. Вот это всё уйдёт в небытие. И поделом.

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

G>>Реактивщина — это же более высокоуровневые вещи, начиная от манифеста и требований к такой системе, и заканчивая интерфейсами. А реализации могут быть разные, в том числе легкопоточные.
G>>Т.е. реактивщина — это философия. А ты говоришь про низкоуровневую реализацию. Ну появятся легковесные потоки, тебе же всё равно нужны будут архитектурные паттерны. Реактивщина их и предоставляет.
G>>Реактивщина дает конкретные ответы на многие вопросы, на которые просто "легковесные" потоки ответа не дают. Например, как построить устойчивую под нагрузкой систему.

vsb>Реактивщина это reactive-streams, project reactor, Spring Webflux. Вот это всё уйдёт в небытие. И поделом.

Reactive Streams — это же просто набор интерфейсов, без реализации. Причем основан на паттернах гофа, которые появились ещё до Java. Чем же эта спека (хотя формально это и не спека) тебе не нравится? И какая разница, как они реализуются, на базе легковесныхпотоков или классических джава-тредов? Это же все инкапсулировано внутри конкретной реализации.
Какие конкретно претензии у тебя к этим технологиям, интересно услышать?

Здравствуйте, kaa.python, Вы писали:

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

G>>Ключевая задача в энтерпрайзной архитектуре — правильно разложить обязанности между системами, причем так чтобы так чтобы были довольны не только пользователи и стейкхолдеры системы, которую ты создаешь, но и стейкходеры других систем.

KP>А чем это отличается от классического современного микро/макросервисного бэкенда на каком-нибудь AWS?

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

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

G>Reactive Streams — это же просто набор интерфейсов, без реализации. Причем основан на паттернах гофа, которые появились ещё до Java. Чем же эта спека тебе не нравится? И какая разница, как они реализуются, на базе легковесныхпотоков или классических джава-тредов? Это же все инкапсулировано внутри конкретной реализации.
G>Какие конкретно претензии у тебя к этим технологиям, интересно услышать?

Конкретные претензии — невозможно читать этот код, невозможно понять проблему по стектрейсу, в нём куча багов, т.к. его нормально никто писать не умеет, причём эти баги неочевидные и не отлаживаются из-за этой асинхронщины.

node.js с его async/await адекватней сделан.

И в неосиляторстве меня не надо обвинять, я как раз осилил всю эту муть и теперь жду-недождусь, пока оно выйдет из моды (в Java).

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

G>>Reactive Streams — это же просто набор интерфейсов, без реализации. Причем основан на паттернах гофа, которые появились ещё до Java. Чем же эта спека тебе не нравится? И какая разница, как они реализуются, на базе легковесныхпотоков или классических джава-тредов? Это же все инкапсулировано внутри конкретной реализации.
G>>Какие конкретно претензии у тебя к этим технологиям, интересно услышать?

vsb>Конкретные претензии — невозможно читать этот код, невозможно понять проблему по стектрейсу, в нём куча багов, т.к. его нормально никто писать не умеет, причём эти баги неочевидные и не отлаживаются из-за этой асинхронщины.

vsb>node.js с его async/await адекватней сделан.

vsb>И в неосиляторстве меня не надо обвинять, я как раз осилил всю эту муть и теперь жду-недождусь, пока оно выйдет из моды (в Java).

Тут я согласен — это сложные вещи. Как кстати и DDD. Но мне кажется, что появление легковесных потоков твои проблемы не решит, т.к. тебе всё равно придется решать те же проблемы. Упрощение может появится только если ты перестанешь думать и решать какие-то из проблем, затронутых реактивностью. "Нет кода — нет проблемы", но в этом случае твоя система просто не будет обладать рядом свойств. Скажем, ты можешь отказаться реализовывать устойчивость системы. Твой нереактивный код действительно станет проще. Но если встанет-таки задача реализовать устойчивость, ты либо нагородишь своих (тоже ведь наверняка сложных!) костылей, либо возьмешь готовые решения от реактивности (тоже сложные, но хотя бы проработанные и стандартные, например шаблоны Circuit Breaker или Bulkhead).
Сложность реактивщины связана с тем, что бизнес требует создания многопоточных надежных систем, а многопоточность и реактивность противоестественны реактивщина (естественна для мышления к сожалению только тупая прямая императивность) — это только второй этап. Первым этапом является просто многопоточность со своими кривыми костылями.
Хотя, если ты умеешь писать некривые костыли на базовой многопоточности — то ок.
Гоф тоже раньше мало кто понимал, применяли криво и неправильно, а прошло 30 лет — и сейчас это уже стало азбукой, которую у джунов спрашивают. Надеюсь, то же будет и с реактивщиной.

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

G>>Reactive Streams — это же просто набор интерфейсов, без реализации. Причем основан на паттернах гофа, которые появились ещё до Java. Чем же эта спека тебе не нравится? И какая разница, как они реализуются, на базе легковесныхпотоков или классических джава-тредов? Это же все инкапсулировано внутри конкретной реализации.
G>>Какие конкретно претензии у тебя к этим технологиям, интересно услышать?

vsb>Конкретные претензии — невозможно читать этот код, невозможно понять проблему по стектрейсу, в нём куча багов, т.к. его нормально никто писать не умеет

А TCK не пробовал для валидации корректности?

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

G>Тут я согласен — это сложные вещи. Как кстати и DDD. Но мне кажется, что появление легковесных потоков твои проблемы не решит, т.к. тебе всё равно придется решать те же проблемы. Упрощение может появится только если ты перестанешь думать и решать какие-то из проблем, затронутых реактивностью. "Нет кода — нет проблемы", но в этом случае твоя система просто не будет обладать рядом свойств. Скажем, ты можешь отказаться реализовывать устойчивость системы. Твой нереактивный код действительно станет проще. Но если встанет-таки задача реализовать устойчивость, ты либо нагородишь своих (тоже ведь наверняка сложных!) костылей, либо возьмешь готовые решения от реактивности (тоже сложные, но хотя бы проработанные и стандартные, например шаблоны Circuit Breaker или Bulkhead).

Мы просто смотрим на это с разных сторон.

Мне не нужна эта устойчивость. Точней нужна, но я не вижу ничего, что мешает мне делать устойчивые системы без реактивщины. Если ты приведёшь конкретный пример, я попробую ответить. Я в курсе про всякие backpressure, но оно всё решается буферами и откидыванием запросов при переполнении буферов (и повторами с другой стороны). И с легковесными потоками это всё естественным образом работает.

Реактивщину используют, т.к. кто-то сказал, что поток на соединение это не масштабируется. А все ведь второй фейсбук пишут, причём который должен работать на ноутбуке. А в реактивщине типа потоки используются более разумно, то-сё. И наш сервис сможет обрабатывать миллионы соединений. А с потоком на запрос — всего лишь тысячи. Вот этого наслушаются и начинают городить эту реактивщину. При том, что простой дубовый код на Spring MVC по факту работает ровно так же, только пишется проще и приносит меньше проблем. Но, видимо, неистребим дух написания хитрого запутанного кода. И я даже не против этого явления, это как с этими модными collection streams делают в 5 строчек то, что с циклом делается в 4, но эта сложность скрыта внутри метода и её никто не видит, а с реактивщиной оно просачивается во все интерфейсы и архитектуру.

И вот с легковесными потоками оно всё начнёт масштабироваться нормально и про реактивщину забудут. Ну я надеюсь, по крайней мере.

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

Могу предложить ещё такой взгляд. Есть язык голанг. В нём легковесные потоки изначально. И насколько популярны в среднестатистическом голанг-приложении реактивные библиотеки (которые, конечно, есть). Я вот, честно, не знаю и было бы интересно услышать.

А в той же Java есть Spring, на котором все пишут. И который RestClient сначала объявил устаревшим, потом одумался и переобъявил в некоем статусе maintained, но всё же WebClient таки является официальной идеологической заменой и теперь всем предлагается им пользоваться, вставляя `block()` в каждый вызов. Что лично меня слегка раздражает.

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

G>А TCK не пробовал для валидации корректности?

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

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

G>>Тут я согласен — это сложные вещи. Как кстати и DDD. Но мне кажется, что появление легковесных потоков твои проблемы не решит, т.к. тебе всё равно придется решать те же проблемы. Упрощение может появится только если ты перестанешь думать и решать какие-то из проблем, затронутых реактивностью. "Нет кода — нет проблемы", но в этом случае твоя система просто не будет обладать рядом свойств. Скажем, ты можешь отказаться реализовывать устойчивость системы. Твой нереактивный код действительно станет проще. Но если встанет-таки задача реализовать устойчивость, ты либо нагородишь своих (тоже ведь наверняка сложных!) костылей, либо возьмешь готовые решения от реактивности (тоже сложные, но хотя бы проработанные и стандартные, например шаблоны Circuit Breaker или Bulkhead).

vsb>Мы просто смотрим на это с разных сторон.

vsb>Мне не нужна эта устойчивость. Точней нужна, но я не вижу ничего, что мешает мне делать устойчивые системы без реактивщины. Если ты приведёшь конкретный пример, я попробую ответить. Я в курсе про всякие backpressure, но оно всё решается буферами и откидыванием запросов при переполнении буферов (и повторами с другой стороны). И с легковесными потоками это всё естественным образом работает.

vsb>Реактивщину используют, т.к. кто-то сказал, что поток на соединение это не масштабируется. А все ведь второй фейсбук пишут, причём который должен работать на ноутбуке. А в реактивщине типа потоки используются более разумно, то-сё. И наш сервис сможет обрабатывать миллионы соединений. А с потоком на запрос — всего лишь тысячи. Вот этого наслушаются и начинают городить эту реактивщину. При том, что простой дубовый код на Spring MVC по факту работает ровно так же, только пишется проще и приносит меньше проблем. Но, видимо, неистребим дух написания хитрого запутанного кода. И я даже не против этого явления, это как с этими модными collection streams делают в 5 строчек то, что с циклом делается в 4, но эта сложность скрыта внутри метода и её никто не видит, а с реактивщиной оно просачивается во все интерфейсы и архитектуру.

vsb>И вот с легковесными потоками оно всё начнёт масштабироваться нормально и про реактивщину забудут. Ну я надеюсь, по крайней мере.

vsb>Я могу предположить, что есть в каких-нибудь одноклассниках сервис, который реально реактивно тарабанит миллионы запросов, и это там надо. Но это очень нишевой случай. С которым надо разбираться, когда ты в этот нишевой случай упёрся. И привносить эту сложность в проект, тщательно изолированную. Но не раньше.

vsb>Могу предложить ещё такой взгляд. Есть язык голанг. В нём легковесные потоки изначально. И насколько популярны в среднестатистическом голанг-приложении реактивные библиотеки (которые, конечно, есть). Я вот, честно, не знаю и было бы интересно услышать.

vsb>А в той же Java есть Spring, на котором все пишут. И который RestClient сначала объявил устаревшим, потом одумался и переобъявил в некоем статусе maintained, но всё же WebClient таки является официальной идеологической заменой и теперь всем предлагается им пользоваться, вставляя `block()` в каждый вызов. Что лично меня слегка раздражает.

Отчасти согласен, я сам реактивщину ещё осваиваю, и не вкусил всех её "прелестей", хотя пару продуктов уже сделали на ней, и накушались проблем, связанных с плохим пониманием этой темы разработчиками, включая меня. Будем надеяться что так и будет, как ты описал. Мне лично реактивщина тоже не по душе, проще обычными многопоточными примитивами обходиться и лепить свои костыли, хотя я и к ним привыкал и осваивал лет 10 наверное, не меньше. Возможно, с реактивщиной так же будет, сейчас кажется жестким бредом "гениальных инженеров" (про "гениальных инженеров" — это цитата из книги Лозинского: "В конце 2013 года собралась группа гениальных инженеров из компаний Lightbend, Netflix и Pivotal, чтобы обсудить описанную проблему и представить решение сообществу JVM. После года напряженной работы мир увидел первый проект стандарта Reactive Streams"), а по истечении 10 лет привыкнем и будем юзать себе в удовольствие, главное мозговые клетки перестроить под реактивный тип мышления.

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

G>Набором сервисов, аутентифцикацией, другой стоимостью и скоростью решений, большим количеством людей, принимающих решения, которых надо удовлетворять.

И чего из перечисленного, на твой взгляд, нет в классическом бэкенде крупной компании? Вроде всё то же. До сих пор не понимаю что такое Enterprise архитектура

vsb>А я бы не советовал изучать реактивщину в Java. В Java в обозримом будущем появятся легковесные потоки, что сделает всю реактивщину бесполезным расходом ментальной энергии.

Можно поподробнее? Про легковесные потоки почитал. Как они могут сделать бесполезной реактивщину?

Здравствуйте, igor-booch, Вы писали:

vsb>>А я бы не советовал изучать реактивщину в Java. В Java в обозримом будущем появятся легковесные потоки, что сделает всю реактивщину бесполезным расходом ментальной энергии.

IB>Можно поподробнее? Про легковесные потоки почитал. Как они могут сделать бесполезной реактивщину?

Реактивщина съест твой мозг сложностью отладки и составления программы. Сами интерфейсы Reactive Streams простые, но составить из них программу тяжело, а отлаживать ещё труднее. Плюс навешиваются АПИ самой реактивной библиотеки, которую ты выберешь, это тоже усложняет понимание.
Но к вопросу — изучать ли реактивщину сейчас или ждать 20 лет, пока оно "рассосется" и появится более легкая в понимании и использовании технология — тебе решать. Реактивщину уже стали внедрять в разработке корпоративного ПО, поэтому ты рано или поздно с ней столкнёшься, и если не будешь понимать её на фундаментальном уровне, то придется вдвойне тяжело. Но если тебе не понравится реактивщина, всегда можно найти приятную и комфортную работу на легаси-копролите, где нет всей этой новомодной шняги.

Здравствуйте, kaa.python, Вы писали:

G>>Набором сервисов, аутентифцикацией, другой стоимостью и скоростью решений, большим количеством людей, принимающих решения, которых надо удовлетворять.

KP>И чего из перечисленного, на твой взгляд, нет в классическом бэкенде крупной компании? Вроде всё то же. До сих пор не понимаю что такое Enterprise архитектура

Скорее всего ваш классический бэкэнд и есть часть Enterprise-архитектуры, разве не? Как он у вас реализован, по какой архитектуре и на каких фреймворках?