Pull to refresh

Comments 10

Скажите, пожалуйста, в электроном формате (pdf, epub) будет ли представлена книга?
Спасибо!

Жаль уже лет 5 не покупаю бумажных книг — нет для них места в доме,
и поиск неудобный.

Это теоретическая книга?

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

Если речь идёт о том, что успешно используется на практике, то в книге явно не хватает обзора реальных примеров. Причём, тут важны не только положительные примеры («вот, посмотрите, как хорошо получается, если делать всё по уму»), но и отрицательные примеры (в том смысле, что если что-то делается не «по уму», то очень важно выявить конкретный источник проблемы). Хотя (кстати!) важны и отрицательные примеры в прямом смысле этого слова, когда показываются ограничения предлагаемого подхода, о которых надо обязательно знать, чтобы не ждать слишком большего и чтобы следить за тем, чтобы применять подход только при условии его применимости (как в физике: «предположим, что имеется идеальный математический маятник с нерастяжимой нитью и пренебрежимо малым сопротивлением воздуха...»).

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

Глава 10 повествует о том, как убедить других в преимуществах DDD и начать применять принципы и приемы этого подхода в своих проектах. Здесь объясняется, почему попытки создать идеальную модель предметной области не так ценны для создания качественного программного обеспечения, как исследования и эксперименты.
Ключевой момент книги, да и всей разработки программного обеспечения!

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

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

P.S. Вот, по моему совершенно скромному мнению, есть одна существенная проблема: реализация всех элементов системы на одном и том же уровне абстракции. Например, если делается приложение, то пользовательские классы находятся там же, где и базовые классы, реализующие числа, строки, списки, очереди, файлы и и.т.д и т.п. Между тем, кажется очевидным, что Вы должны создать, сначала, некую инфраструктуру, чтобы ввести понятие «программного объекта» (основного объекта, с которым Вы будете дальше работать в приложении), а это значит, что Вы никогда не будете использовать структуры для представления отдельных записей таблиц баз данных, зато Вы всегда будете иметь под руками метаданные, позволяющие Вам задавать локальные проверки обрабатываемых данных и то, что именно должно отображаться в пользовательском интерфейсе.

Другая сторона вопроса — это то, что можно назвать «безИсходным программированием» (без исходников). Если бы программы позволяли бы создавать свои же собственные исходники, то процесс модернизации программного обеспечения существенным образом упростился бы. Например, было бы достаточно иметь в операционной системе компилятор, конфигуратор, приложение и кодовое представление новых требований (фич), то, «распечатав» программу в конфигураторе и осуществив слияние «распечатки» с новыми требованиями, можно было бы пропустить результат через компилятор и получить новую версию приложения, учитывающую более детальную схему предметной области.

И, последнее. Важнейший источник проблемы проектирования программных систем заключается в том, что приложения создают сразу на целевом языке программирования. Между тем, начальное (проектное) состояние приложения должно существенно отличаться от конечного продукта. Условно говоря, конечный программный продукт должен получаться в результате «распечатки» из-под проекта той же системы. При этом, вовсе не обязательно, чтобы язык реализации проекта совпадал с языком реализации конечного приложения. Скорее, наоборот, каждый язык программирования должен определяться кругом решаемых задач…

P.P.S. Что-то я очень много написал! Остановлюсь. А то в ответ на одну книгу придётся написать другую. Хотя, да, было бы крайне любопытно (если будет возможность почитать сам книгу), детально проанализировать её на страницах Хабра. Но что, уж точно, не помешало бы, так это снабдить книгу толстенным томом с описанием конкретных примеров и с указанием как ошибок, так и достижений.

Будет ли электронная версия книги?

Наверное нет
https://habrahabr.ru/company/piter/blog/333696/#comment_10319168
Любопытно было посмотреть на отрывок, предоставленный на сайте издательства. Там представлено начало главы 12 («Интеграция посредством обмена сообщениями»).

1. Глава начинается с раздела «Загружаемые примеры кода для этой главы», но к этому разделу относится только первый абзац. Затем идёт нормальное введение в главу. Почему так сделано?

2. Далее, начинается, собственно, описание шины сообщений: «Если в системе имеется единственный централизованный компонент, отвечающий за отправку всех сообщений, вся система может обрушиться, если этот компонент прекратит работу». Наверное, книга очень толстая. 832 страницы! Иногда кажется, что объём можно сократить, делая небольшие введения, чтобы не объяснять в разных местах книги то или иное соображение.

3. Также имеется ссылка на рисунок: «Шина сообщений обеспечивает коллективную работу всех частей, как показано на рис. 12.1.». Какой смысл в этом рисунке? Между прочим, он занимает место, но совершенно ничего не добавляет к сказанному в тексте, и, уж точно, не показывает, как именно шина сообщений обеспечивает коллективную работу, поскольку на рисунке показаны только сами связи. Картинка имела бы смысл, если бы на ней изображались какие-то важные детали реализации.

4. Автор(ы) пишут, что «Централизованный компонент, принимающий и рассылающий все сообщения, называют брокером сообщений (message broker), или просто брокером». Интересно, рассказывают ли авторы в своей книге о CORBA? И, если шире ставить вопрос, что они говорят о предшествующих попытках предложить что-то вроде предметно-ориентированного подхода?

5. Также, имеется любопытное примечание:
Как упоминалось в предыдущей главе, под компонентами в этой главе понимаются отдельные приложения, которые можно распространять и развертывать независимо друг от друга. Вы также можете встретить такие названия, как «автономные компоненты» (autonomous components), «распределенные компоненты» (distributed components), «компоненты, обменивающиеся сообщениями» (messaging components) и даже «микрослужбы» (micro services). К сожалению, сообщество разработчиков пока не нашло точного, однозначного и непротиворечивого названия.
От основополагающей книги ожидаешь, что в ней самой предлагается своя чёткая терминология, устраняющая разнобой и позволяющая понять, чем должен быть компонент на самом деле.

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

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

Тираж закончился, несколько экземпляров осталось по розничным точкам (в основном Минск, 4 экз). В РФ, судя по всему, осталось 2 экземпляра: в магазине издательства (Питер, Большой Сампсониевский 29); Москва, в Библио Глобусе, их каталог показывает, что книга ещё в наличии. Вероятно это последние экземпляры в РФ.
Sign up to leave a comment.