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

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

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

А тебя интересует jee/spring или дотнет?

G>А тебя интересует jee/spring или дотнет?

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

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

G>>А тебя интересует jee/spring или дотнет?

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

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

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

IB>Посоветуйте книги (или блоги) по enterprise архитектуре,

А что такое Enterprise архитектура? У меня просто сразу картинки в голове рождаются типа "как запилить огромный опердень монолит и не помереть", или это о чем-то другом?

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

Тут все так дружно за анемичную модель топили лет 10 назад. Что все, мода поменялась?

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

G>Кстати, реактивщина и DDD сейчас входят в моду,

А на чем основан такой вывод? (как бы DDD уже не первый год в ходу)

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

IB>>Посоветуйте книги (или блоги) по enterprise архитектуре,

KP>А что такое Enterprise архитектура? У меня просто сразу картинки в голове рождаются типа "как запилить огромный опердень монолит и не помереть", или это о чем-то другом?

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

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

G>>Кстати, реактивщина и DDD сейчас входят в моду,

Doc>А на чем основан такой вывод? (как бы DDD уже не первый год в ходу)

Под "сейчас" я имею ввиду не "2021" год, а скорее последнее десятилетие. В энтерпрайзе же все не так быстро, да и хорошие книги по теме выходят не часто. Я тут имею ввиду, что скажем читать старые книги по ранним версиям EJB или старые книги Фаулера — это уже не так актуально, хотя для понимания темы или легаси-копролита может и имеет смысл. Потому что современные EJB переняли идеи Спринга по облегченным компонентам, так что если и читать по EJB, то начиная с JEE 7, скажем учебник Гонзалвеса "Изучаем JEE7" можно было бы посоветовать ТСу в кач-ве отправной точки, если бы он джава-энтерпрайзом интересовался.

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

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

_>Тут все так дружно за анемичную модель топили лет 10 назад. Что все, мода поменялась?

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

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

G>Под "сейчас" я имею ввиду не "2021" год, а скорее последнее десятилетие.

К такой трактовке вопросов нет

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

G>>А тебя интересует jee/spring или дотнет?

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

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

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

G>>А тебя интересует jee/spring или дотнет?

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

Еще кстати, я бы добавил в список к чтению книгу типа "Распределенные паттерны" Бёрнса, очень годное чтиво, сейчас же всё на докере и кубере работает, в ней как раз такие паттерны описаны. Я когда её начал читать, стал понимать зачем докер+кубер нужны и как их использовать, в каких кейсах.

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

IB>Посоветуйте книги (или блоги) по enterprise архитектуре, в которых упор делается на максимально детальный разбор реальных примеров из жизни.
Вспомнился старый афоризм: "Примеры описанные в книгах о лидерстве никогда не читали книг о лидерстве". С архитектурой так же — примеры хорошей архитектуры из книг вряд ли основаны на других примерах из других книг.


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

Есть три вида книг: справочник, учебник и руководство.

1) Справочник — содержит правила\принципы\приемы\функции и "иллюстрации" к ним. Справочник крайне полезен, но по нему нельзя научиться решать задачи. Примеры — GoF, POEAA, Reactoring to patterns, Designing Data-Intensive Applications и еще несколько похожих книг
2) Учебник обычно содержит одну историю в рамках которой показано как применять те или иные правила\принципы\приемы\функции. Примеры — ООАД Буча, DDD и куча учебников от вендоров по их технологиям. Проблема учебников в программировании в том, что они всегда описывают нереалистичные приложения. Если учиться программировать или проектировать только по учебникам, то будет получаться буллшит.
3) Руководства — описывают что надо делать или не надо, могут быть похожи на справочники если пытаются охватить обширную область. Из известных мне руководств широкого профиля: Clean Code и Pragmatic Programmer, узкого: Framework Design Guidelines для .NET.

Что касается проектирования и архитектуры, то я бы рекомендовал Design of Design Брукса (того самого который написал Мифический Человеко-Месяц). Это хорошее руководство про самому процессу проектирования, оно необходимо чтобы отличать нормальные материалы от буллшита. Это вряд ли похоже на то, что вы ищите

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

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

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

IB>>Посоветуйте книги (или блоги) по enterprise архитектуре,

KP>А что такое Enterprise архитектура? У меня просто сразу картинки в голове рождаются типа "как запилить огромный опердень монолит и не помереть", или это о чем-то другом?

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

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

KP>А что такое Enterprise архитектура? У меня просто сразу картинки в голове рождаются типа "как запилить огромный опердень монолит и не помереть", или это о чем-то другом?

Шаблоны корпоративных приложений. Мартин Фаулер.

Но что именно подразумевает понятие корпоративное приложение (enterprise application)? Точное определение сформулировать трудно, но дать смысловое толкование вполне возможно. Начнем с примеров.

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

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

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

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

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

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

IB>Посоветуйте книги (или блоги) по enterprise архитектуре

1) "чистая архитектура" Р. Мартин
2) https://smarly.net/pro-asp-net-mvc-4/introducing-asp-net-mvc-4/sportsstore-a-real-application

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

Очень интересно, что почитать про связь реактивщины и rich модели?
Посмотрел https://www.infoq.com/presentations/reactive-ddd/
Про реактивность понятно, но как она связаны с rich и anemic?
Или, может сами объясните поподробней

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

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

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

Я, собственно, что пытаюсь прояснить. Когда я слышу "энтерпрайзной архитектуре" мне сразу какая-то окаменелось на Java/C# из БОЛЬШОГО БАНКА (ага, всё заглавными) приходит в голову и всё. Просто модный и современный бэкенд так не кличут никогда

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

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

IB>Очень интересно, что почитать про связь реактивщины и rich модели?
IB>Посмотрел https://www.infoq.com/presentations/reactive-ddd/
IB>Про реактивность понятно, но как она связаны с rich и anemic?
IB>Или, может сами объясните поподробней

Связи между реактивщиной и rich/anemic моделями нет. Реактивщина — это набор паттернов и стандартов для реализации в системе реактивности.
Что такое реактивность? Как и у эджайла, есть манифест реактивщины:
https://www.reactivemanifesto.org/ru

Почитать рекомендую книгу Лозинского "Практика реактивного программирования в Spring 5", сам её сейчас изучаю и она неплохо описывает эту тему, в ней много сложных примеров из реальной жизни, то, что ты и ищешь. Других книг не читал, читал ряд статей, но статьи не дают хорошего понимания реактивщины.

И вот пример статьи например про шаблоны реализации отказоустойчивости таких систем:
https://sysout.ru/otkazoustojchivost-mikroservisov-shablon-circuit-breaker/

В реактивщине могут использоваться как Rich, так и Anemic модели предметной области.

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-архитектуры, разве не? Как он у вас реализован, по какой архитектуре и на каких фреймворках?

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

Понимаю, что ты наверное явист, но вдруг сможешь что-то сказать о
https://github.com/IgorBuchelnikov/ObservableComputations
В этой библиотеке реактивность основана на дотнетовских интерфейсах INotifyPropertyChanged and INotifyCollectionChanged
но может оборачивать интерфейсы из Reactive Extensions (дотнетовкий аналог Reactive Streams)
Делал эту библиотеку в основном для UI, но как ты думаешь,
можно ли её в бэкэнде как то применить (в enterprise архитектуре)?

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

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

IB>Понимаю, что ты наверное явист, но вдруг сможешь что-то сказать о
IB>https://github.com/IgorBuchelnikov/ObservableComputations
IB>В этой библиотеке реактивность основана на дотнетовских интерфейсах INotifyPropertyChanged and INotifyCollectionChanged
IB>но может оборачивать интерфейсы из Reactive Extensions (дотнетовкий аналог Reactive Streams)
IB>Делал эту библиотеку в основном для UI, но как ты думаешь,
IB>можно ли её в бэкэнде как то применить (в enterprise архитектуре)?

Вот это поворот))
Вообще, для реактивщины есть определенные контракты, и есть библиотека для их верификации на соответствие этим контрактам — TCK (Technology Compatibility Kit), для дот-нета в том числе.
Так что в первую очередь тебе нужно, чтобы твоя либа проходила все эти тесты. Это по поводу реактивных контрактов. А по поводу применимости в энтерпрайзе, завтра внимательнее погляжу на твое творение в этом разрезе, с позиций энтерпрайзного джава-разработчика.

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

Многопоточность и асинхронность, на базе которой основана реактивность, совсем разные вещи.

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

Ну ты то, вижу, точно ничего не читал

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

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

IB>Понимаю, что ты наверное явист, но вдруг сможешь что-то сказать о
IB>https://github.com/IgorBuchelnikov/ObservableComputations
IB>В этой библиотеке реактивность основана на дотнетовских интерфейсах INotifyPropertyChanged and INotifyCollectionChanged
IB>но может оборачивать интерфейсы из Reactive Extensions (дотнетовкий аналог Reactive Streams)
IB>Делал эту библиотеку в основном для UI, но как ты думаешь,
IB>можно ли её в бэкэнде как то применить (в enterprise архитектуре)?

Посмотрел, документация в readme неплохая. Но бросается в глаза, что в коде нет комментариев, а также коммиты все идут в одной ветке и с плохими коммит-мессаджами — это не создает ощущения продукта для энтерпрайза, коммьюнити у продукта тоже нет судя по всему? Еще бы не помешало написать, это как-то связано с Reactive Streams и проч. реактивными стандартами?
В текущем виде библиотеку вряд ли кто-то всерьез будет рассматривать для энтерпрайза. Нужно коммьюнити, ссылки на реально используемые проекты, также непонятно как дела уязвимостями и CVE.

G>Но бросается в глаза, что в коде нет комментариев
С комментариями проблема. Документирующие комментарии для пользователей,
либо очевидны из названия члена (тупые комментарии писать не хочется),
либо требуют развернутого объяснения, которое приведено в readme.
Но некоторые комментарии, согласен, не мешало бы добавить.

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

G> коммьюнити у продукта тоже нет судя по всему?
А где его взять? Вот думаю выступить на какой-нибудь встрече с докладом.


G> Еще бы не помешало написать, это как-то связано с Reactive Streams и проч. реактивными стандартами?
Отсюда как бы очевидно (если предыдущие главы почитать). System.Reactive это пространство имен для реализации реактивного стандарта dotnet

G>Нужно коммьюнити, ссылки на реально используемые проекты,
Opensource проекты?

G>также непонятно как дела уязвимостями и CVE.
Уязвимости, наверное, такие же как для библиотек dotnet, на которые ссылается ObservableComputations. А ссылок мало и только на базовые библиотеки

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

G>>Но бросается в глаза, что в коде нет комментариев
IB>С комментариями проблема. Документирующие комментарии для пользователей,
IB>либо очевидны из названия члена (тупые комментарии писать не хочется),
IB>либо требуют развернутого объяснения, которое приведено в readme.
IB>Но некоторые комментарии, согласен, не мешало бы добавить.

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

G>>, а также коммиты все идут в одной ветке и с плохими коммит-мессаджами
IB>Да, я с ними не заморачивался,
IB>так как был и остаюсь единственным разработчиком.
IB>Если появится ещё разработчики, тогда месседжи конечно будут нужны,
IB>ещё можно сделать документацию для разработчика,
IB>коммит месседжи старых комитов вряд ли помогут

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

G>> коммьюнити у продукта тоже нет судя по всему?
IB>А где его взять? Вот думаю выступить на какой-нибудь встрече с докладом.

Конечно, нужен доклад, нужна статья в блоге с литературным описанием (завязка-интрига-развязка) какие проблемы эта библиотека решает, почему разработчики должны выбрать именно её?


G>> Еще бы не помешало написать, это как-то связано с Reactive Streams и проч. реактивными стандартами?
IB>Отсюда как бы очевидно (если предыдущие главы почитать). System.Reactive это пространство имен для реализации реактивного стандарта dotnet

G>>Нужно коммьюнити, ссылки на реально используемые проекты,
IB>Opensource проекты?

Для начала да. Чтобы посмотреть реальные кейсы применения твоей либы.

G>>также непонятно как дела уязвимостями и CVE.
IB>Уязвимости, наверное, такие же как для библиотек dotnet, на которые ссылается ObservableComputations. А ссылок мало и только на базовые библиотеки

Без этой инфы либа тоже не вкатится в энтерпрайз. Там же все либы постоянно чекаются на секьюрити. Если у либы нет этой инфы, либо если инфа есть и есть дыры в безопасности, то такая либа просто поступает на карантин и энтерпрайз-проекты, зависящие от неё, не собираются devsecops-пайплайном системы сборки.

И еще нужна четкая инфа по лицении продукта.

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

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

IB>>>Посоветуйте книги (или блоги) по enterprise архитектуре,

KP>>А что такое Enterprise архитектура? У меня просто сразу картинки в голове рождаются типа "как запилить огромный опердень монолит и не помереть", или это о чем-то другом?

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

Всё это нужно для корпорации с каким количеством сотрудников? Просто если в конторе софтиной пользуются полтора человека один раз в месяц, то зачем заморачиваться?

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

KP>>>А что такое Enterprise архитектура? У меня просто сразу картинки в голове рождаются типа "как запилить огромный опердень монолит и не помереть", или это о чем-то другом?

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

V>Всё это нужно для корпорации с каким количеством сотрудников? Просто если в конторе софтиной пользуются полтора человека один раз в месяц, то зачем заморачиваться?

Практика показывает, что даже мелкий заказчик часто хочет и авторизацию по токену, и логирование, и сбор метрик, и полнотекстовый поиск, и секьюрность с блэкджэком и https. К счастью, в джаве есть проекты типа JHipster, которые позволяют буквально за 5 минут сгенерировать полноценный проект с бэком и фронтом на основе предоставленной доменной модели данных, и включающий в себя большинство энтерпрайзных практик, а сгенеренный код будет соответствовать общепринятым парадигмам. Потом просто допиливаешь этот код под нужные детали.

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

IB>>>>Посоветуйте книги (или блоги) по enterprise архитектуре,

KP>>>А что такое Enterprise архитектура? У меня просто сразу картинки в голове рождаются типа "как запилить огромный опердень монолит и не помереть", или это о чем-то другом?

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

V>Всё это нужно для корпорации с каким количеством сотрудников? Просто если в конторе софтиной пользуются полтора человека один раз в месяц, то зачем заморачиваться?

Все энтерпрайзные спеки выросли из конкретных потребностей. Поэтому в первую очередь для себя нужно этими всем владеть. Если не владеешь какой-то спекой или энтерпрайзной технологией, высоки шансы что просто не будешь уметь решать такие задачи и находить соотв.баги у крупного и серьезного заказчика. Например, если человек не владеет уровнями изоляции транзакциями, которые для мелкого заказчика можно вроде как и не использовать, он не сможет решать целый спектр задач и специфичных багов. Так что если уж взялся работать с мелким заказчиком, то это отличный полигон обкатать все эти вещи для повышения своей экспертизы, без сильных последствий в случае фэйла или срыва сроков.

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

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

В случае с багами Log4J, что привело к проблемам? Каких экспертных знаний и кому не хватило?

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

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

V>В случае с багами Log4J, что привело к проблемам? Каких экспертных знаний и кому не хватило?

Инфосек вообще не так давно стал широко внедряться в энтерпрайз, с появлением девсекопса. Но территория все равно ещё для большинства энтерпрайзных разрабов дикая и мало освоенная. Так что предположу, что это проявление общей проблемы плохого внедрения инфосека в энтерпрайз. Хорошие спецы по нему есть, но это параллельный мир, который мало пересекается с миром разрабов. Пересечение происходит разве что в точках девсекопса — например в пайплайнах, проверяющих уязвимости в коде, или репозиториев типа нексуса, которые умеют переводить библиотеки на карантин, или в эпизодических проверках системы пентестерами. Но девсекопс сам еще не созрел и не везде внедрен, а где внедрен, то не полностью (например, используются не все виды проверок).
Возможно, авторы этой библиотеки вообще не обращали внимание на отчеты по уязвимостям, а может даже сами и не проводили их, т.к. хорошие инструменты стоят очень дорого (чекмаркс например стоит десятки тысяч долларов в год для небольшой команды).
Надежда тут скорее всего только на то, что сами репы, типа гитхаба, будут бесплатно внедрять инструменты девсекопса, и либа просто не будет собираться там если имеет уязвимости. Потому что ждать от самих энтерпрайзных разрабов повышения квалификации в инфосеке слишком оптимистично, им бы фуллстэк, ddd и реактивщину освоить, не до инфосека, если только какие-то базовые правила, типа не логировать сессию и не хранить пароли в открытом виде в стринге.

Здравствуйте, Vladek, Вы писали:
V>В случае с багами Log4J, что привело к проблемам? Каких экспертных знаний и кому не хватило?
Я так понимаю, что в основном не хватило фантазии придумать контрпример.
То есть вроде как сама по себе идея лукапов в чём-то здравая. По крайней мере, сложно сразу же придумать равномощное решение.
Тем более, что она придумана вовсе не в log4j, а далеко за его пределами. К примеру, при разрешении конфигурационных параметров почти везде принято раскрывать $-ссылки, причём рекурсивным образом. Нуачо, прикольно же — когда у тебя префикс имени переменной задаётся в другой переменной. Типа ${${context}path}\${${context}_filename} — и вот, можно одной строкой переключаться между ${staging_path}, ${staging_filename} и ${production_path}, ${production_filename}.
Офигенно же удобно.
Ну, вот и решили, что раз такая пьянка возможна в конфигурации, то почему бы не сделать её и в логгировании.
А вот дотумкать, что если в конфигурацию доступ посторонним запрещён, и можно полагаться на отсутствие в ней неожиданных jndi:ldap:... обращений, то в логгирование попадает произвольная порнография, приходящая из недоверенных источников, не вышло.
Я даже не знаю, есть ли способ отследить подобные вещи каким-нибудь статическим анализатором.