😐 Кто здесь?

Лучков Александр. Интересующийся архитектор. Увлечённый инженер.

🤔 Зачем мне этот канал ?

Я здесь веду свои рабочие заметки. Основные типы заметок:
- О разбираемой литературе. Книжки. Задачки. #книжнное
- О проектах. В разработке. Завершённых. Планируемых. #рабочее
- О мыслях и идеях связанных с инженерными практиками #идейное.

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

🙄 А мне сюда зачем?
Мне кажется, вам этот канал может пригодиться если:
- Вам интересны разборы классической и не очень инженерной литературы. Впечатления о ней. Результаты применения знаний оттуда почёрпнутых.
- Вы интересуетесь сходными со мной темами. Например: Организацией проектирования сложных штук, Инженерией (с большой буквы, как областью деятельности человеков).
- Хотите вежливо, обоснованно и с точки зрения конкретной абстрактной или реальной задачи пообсуждать в комментах с единомышленниками отношение к местным вещам.

Заметка на полях. Начал разбирать новую книжку. Введение и предисловие хороши. Но разбирать не буду)
Заметка на полях. Первая глава "Изучаем DDD". Анализ предметной области.

Что порадовало:

✔️ Структура изложения. Тематически собрано очень приятно и целостно.
✔️ Очень точный эпиграф. Взял на вооружение.
✔️ Просто делать выводы.
✔️ Наличие задач.
✔️Изложен принцип, что домены выделяются только в деятельности, а не в её описаниях. Пусть даже в головах очень важных людей. В головах - гипотезы. В деятельности - факты. Иногда они совпадают. Но это не точно, и обязательно требует проверки.
✔️Юзкейсы - классная штука. Оказывается, я не просто так их учил. И архитектору важно знать технику. Заодно порекомендую Ивара Якобсона с его "UseCase 2.0". Мне очень помогло в своё время.
✔️Дан критерий предела детализации анализа при выделении доменов. Бинго!
✔️Подчёркнута необходимость участия предметников в разработке продукта. Ещё раз. В очередной.

Чего хотелось бы добавить или сделать лучше:

✔️Добавить примеров относительно целей некоммерческих организаций. Мне кажется там колоссальное поле для вспашки. Особенно в этом поле.
✔️Перескакивание в рамках одного раздела между разными объектами рассуждения. Так-то хорошо, поскольку разделы короткие. Но хотелось бы "инженерного совершенства" с точки зрения метода подачи материала. Например между описаниями различий основных и универсальных доменов местами прыгает рассуждение, что усложняет восприятие.
✔️Несколько слов о прочих заинтересованных сторонах и культурных аспектах. Зацепить историю о командообразовании в отношении разных типов поддоменов. Мне кажется, что "с кем работать" не менее важно чем "над чем".
✔️Бизнес, в контексте нашей культуры, это исключительно про деньги. А он, на самом деле, про любую деятельность приносящую любой тип выгоды, с точки зрения предпринимателя. Тут это потеряно. А хотелось бы.

Какие выводы:

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

Что дальше:

Буду в своём репозитории публиковать решения задачек даваемых в книжке. О чём кстати, можно будет подискутировать.

#книжное #DDD #ПОП #глава1 #Хононов

Заметка на полях. Вторая глава "Изучаем DDD". Экспертные знания о предметной области.

Что порадовало:

✔️ Ещё раз, для всех особо одарённых повторили, что предпринимательская задача - не описывается полностью, в общем случае, формальным языком. Надеюсь - начнёт доходить.

✔️Сформулирован тезис, что компания нужна ради решения задач Клиентов. Я понимаю, что это расширительное толкование, но в этом случае каждый, чьи задачи решает компания - её клиент. Что несколько меняет подход и отношение к организации деятельности любого участника предприятия.

✔️Показали важность верификации создаваемой документации относительно экспертов в области той деятельности, где разрабатывается решение. Ещё раз. Опять же, может быть хоть теперь дойдёт.

✔️Косвенно указали, что тезис Фила Дельгядо : "Если в вашей компании есть системный аналитик - у вас проблемы" - имеет право на жизнь. Поскольку увеличивает количество звеньев во ВСЕГДА испорченном телефоне преобразования моделей из области задачи в область решения (problem space into solution space).

✔️Указали на важность коммуникации и снятия коммуникационных барьеров в командах. Собственно разделяемое командой (а то и организацией) знание о предметной области в этом контексте должно быть священной коровой. Но, пока нет.

✔️Указали на важность моделирования предметной области.

Чего хотелось бы добавить или сделать лучше:

✔️Более предметно проговорить на каком уровне появляются технические детали, поскольку основной тезис главы: - "Разработчик должен уметь с предметниками и предпринимателями говорить на языке предпринимательской деятельности в предметной области". И тут, мне кажется есть противоречие. Поскольку у разработчика голова одна, то он её либо использует в целях углубления знаний о предметной области, либо грузит в неё технологии. Мне кажется, что такая постановка вопроса противоречит сути идеи разделения труда. И возникает куча вопросов. Например:
- Если всё предприятие в повседневном (sic) общении говорит на Едином Языке, который и есть "язык предметной области" он же "язык бизнеса", то на ком лежит сложность перевода между основными доменами, выявление и устранение противоречий в языке и деятельности?
- Если в едином повседневном языке обсуждения решений отсутствуют технические детали, то в каком месте они появляются? У меня есть гипотезы, но хотелось бы послушать мнение авторов.

✔️Примеры в книге с указанием, что где-то используется тех.жаргон в предметной области - мне кажутся нарушением применения принципа разделения интересов (separation of concerns) и нарушением принципа фокуса внимания при рассмотрении какой-то системы. Поскольку не содержат указаний на контекст высказывания и цели, поставленные перед собой автором высказывания. В контексте моего, надеюсь временного, непонимания, где начинаются технические детали это меня беспокоит.

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


Какие выводы:

✔️Есть большая область для раскопок в части границ применимости "Единого языка предметной области". Поскольку вопросы его применимости - открыты. Возможно я сниму эти вопросы при чтении глав в дальнейшем, но пока есть.

✔️Есть запрос на средства моделирования предметной области. Пока ничего лучше UML и страниц в Wiki вроде бы не придумали. Но по-хорошему сюда бы АИшечку с LLM подтянуть. Мне кажется, что тут колоссальный простор для улучшения и творчества.

✔️У нас в разработке почти всегда находится множество доменов, и почти всегда есть команды работающие на более чем один домен, то достаточно часто будут возникать ситуации, где потребуется согласование языка общения таких специалистов. Чтоб проблема синонимов или омонимов их допекала меньше. А она допекает. Когда под термом "клиент" понимают совершенно разные сущности в двух соседних доменах.

#книжное #DDD #ПОП #глава2 #Хононов

Что дальше:
✔️Было бы хорошо подумать о том, какими инструментами в нынешней ситуации можно достаточно хорошо моделировать предметную область. Кажется, что имеющиеся на данный момент слишком уехали от реальности.

#книжное #DDD #ПОП #глава2 #Хононов

Заметка на полях. Третья глава "Изучаем DDD". Как осмыслить сложность предметной области.

Что порадовало:
✔️ Вопросы противоречивости возникшие у меня при чтении второй главы тут более-менее разрешаются.
✔️ Подтвердил свой старый тезис, что смысл работы архитектора в том, чтобы "давать имена". Т.е. создавать/выделять понятие, насыщать их смыслами, и контролировать эту историю.
✔️В очередной раз убедился, что "Перспектива"(viewpoint) для "Модели" - неотъемлемая часть.
✔️Без воды, на пальцах, раскидано как работать с ограниченными контекстами.
✔️Описаны свойства Ед.Языка и его сопоставление с Огр.Конт.
✔️Закон Конвея учтён, что есть круто)

Чего хотелось бы добавить или сделать лучше:
✔️Примеров единого языка хотелось бы пореальнее. Можно внешними ссылками на статьи, или работы. Чтобы набрать больше эмпирик.
✔️Очень спорный для меня тезис, что разработчик не определяет требования. С моей точки зрения "ограничения" - это вид требований, которые как раз задаются возможностями команды разработки. Да, они в свою очередь настраиваются другими ресурсами, но...
✔️Тезис "системные требования предметной области" - выглядит крайне странно. Мне сходу не удалось его достаточно однозначно интерпретировать. Кажется, требует раскрытия.

Какие выводы:
✔️ Каждый раз, когда кто-то рисует квадратики и спрашивать с него "А какую ты задачу решал этой моделью".
✔️ Хочу практикум по ограниченным контекстам. Чуть ли не учебник. Очень.
✔️ Хочу практикум по моделированию. Опять же, чуть ли не учебник. Тоже очень.
✔️ Пора читать теорию распределённых вычислений. Похоже, что согласование ментальных моделей экспертов Пр.Обл. - задачка из этой области.

Что дальше:
✔️Классно было бы подумать над тем, какие из популярных моделей какие задачи решают в реальности, и как это соотносится с их начальным назначением, или тем, что пишут в статьях.
✔️Похоже, что такая штука как DSM - это неплохой способ выделения Огр.Конт. на множестве сценариев (а может быть и над семантической областью ). Надо бы проверить.
✔️Решать задачки.

P/S. Репу пока не сделал. Каюсь.

#книжное #DDD #ПОП #глава3 #Хононов

Заметка на полях. Четвёртая глава "Изучаем DDD". Способы сопряжения ограниченных контекстов.

Что порадовало:

✔️Первая книжка, где я вижу прямой учёт правила Конвея в части проектирования.
✔️Наконец-то кто-то учёл, что процессы - это люди, а не "нечто, что рожает код". Поэтому фокус дан в т.ч. на необходимые качества отношений между людьми, для применения подхода к сопряжению компонентов=доменов.
✔️Язык изложения продолжает радовать. Всё так же мало воды, по сравнению с другими книгами, и высокая насыщенность смыслами.
✔️Полезную модельку дали =) Причём сразу сказали для каких задач её точно можно использовать.

Чего хотелось бы добавить или сделать лучше:
✔️Очень нехватает упражнений и задач. Хоть семинары открывай.
✔️Чтобы понимать ценность материала, нужно иметь нетривиальный опыт. Для новичка бы это выглядело как "10 заповедей на каменных скрижалях". А хотелось бы обоснования, раскрытия. Например примеров неудачных решений.
✔️Немножко структурировать разделы, кажется, что в некоторых местах есть перескакивание между мыслями, и из-за этого мне приходилось напрягаться. Но это так, ворчание ленивого.


Какие выводы:

✔️Если мы - архитекторы, и хотим хорошо эволюционировать со своей системой - следим за динамикой развития интерфейсов как между кусками комплекса системы, так и между командами.
✔️Если даём какие-то модели - сразу нужно говорить для решения какой задачи они подходят. Уже было, но повторить не лень.

Что дальше:

✔️Похоже, что кому-нибудь стоит заняться задачником по DDD. Если некому, значит пока не время.
✔️Нужно развивать практикумы. Возможно, сделаю регулярный семинар, правда не очень понятно, в каком виде это может полететь, и кому нужно. Я так точно этим в какой-то момент займусь.

#книжное #DDD #ПОП #глава4 #Хононов

Заметка на полях. Пятая глава "Изучаем DDD". Реализация простой логики предметной деятельности.

Что порадовало:
✔️Методы рассматриваются, на мой взгляд, достаточно подробно. Как человеку не имеющему большого опыта непосредственной разработки ПО (классы-методы-код), смотрится здраво.
✔️Хорошо описаны критерии применимости. Но от недостатка опыта мне может быть сложно оценить полноту и значимость описания.
✔️Есть задачки к этой главе.

Чего хотелось бы добавить или сделать лучше:
✔️Поскольку есть ссылки на Фаулера, наверное стоило бы дать какой-то перечень способов реализации логики. Пока выглядит как достаточно вырванное из контекста. Нехватает отсылок к кругозору, и где копать для желающих большего.
✔️Хотелось бы различения простой и сложной логики деятельности. Мне кажется, это различение крайне важно. Даже CRUD может быть достаточно сложно реализуемым под капотом в некоторых случаях.

Какие выводы:
✔️В целом идёт хорошо.

Что дальше:
✔️Поставить в задачи посмотреть Фаулера "Patterns of enterprise application architecture".
✔️Было бы неплохо найти куски кода, и сформулировать вокруг них задачи на различение паттернов. Может сойти за кандидатскую работу к.м.к.

#книжное #DDD #ПОП #глава5 #Хононов

Заметка на полях. Пятая глава "Изучаем DDD". Проработка сложной логики предметной деятельности

Что порадовало:
✔️Всё ещё хорошо понятный язык изложений сложных концепций. Правда возможно это следствие моей общей подготовки и кругозора. Поэтому нужно проверять на других коллегах. На мой взгляд это редкость для таких книг.
✔️Указания на некоторые типичные ошибки допускаемые при проектировании.
✔️Хорошо видно, что сложность коммуникаций между людьми в процессе разработки можно перенести на формальные инструменты за счёт оптимального выстраивания поля понятий, которыми участники коммуникации оперируют. Язык действительно многое решает. Очень. Интересно до каких пределов это возможно?

Чего хотелось бы добавить или сделать лучше:
✔️Указание на то, какими практиками или приёмами выделять те, или иные типы объектов. Хотя бы ссылочно. Например про EvStorm упоминаний нет, а про события П.О. - есть. Мне кажется это было бы полезно.
✔️Описаны агрегаты, доменные сервисы и объекты-значения. При этом во введении упоминались инварианты и бизнес-правила. А на них ссылок по ходу главы нет. Возможно я чего-то недопонял и это будет дальше, но пока не заметил где про это можно прочитать.

Какие выводы:
✔️Мне не очевидно сходу, какими навыками должен обладать инженер проектирующий системотехнические решения с применением П.О.Пр. Поскольку тут и "контроль системного уровня" ( о чём кстати явно не говорится), и разделение объектов по множеству оснований, и удержание множества аспектов приложения внимания одновременно.
✔️Похоже про практические задачи надо действительно делать отдельную книжку) Мне вопросы для самоконтроля показались слабыми, и не требующими закрепления материала.
✔️Пошли главы по большей части именно для программистов. А хотелось бы больше про системотехнический уровень. Ещё интересно было бы про программно-аппаратное проектирование почитать, насколько П.О.Пр применимо в этой сфере. Хотя похоже такой перенос это предмет для исследования.
✔️Вроде бы, у меня создаётся впечатление, что при заходе на ООП через П.О.Пр сложновато что-то новое изобрести.

Что дальше:
✔️Пока фиксируем хотелки, но похоже, что можно планировать семинар по обсуждению книги и её аспектов, чтобы вынести на обсуждение что там хотели бы получить. Я вот задачник по П.О.Пр. хочу, чтобы можно было практиковаться.

#книжное #DDD #ПОП #глава6 #Хононов

Заметка на полях 9.11.2023.

Организовали с коллегами небольшой семинар системных инженеров (они же инженеры-системотехники, не путать со схемотехниками). Посмотрим как пойдёт. Сюда же буду публиковать некоторые результаты обсуждений. Примеры тем, которые у нас возникают:

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

#рабочее #incose #системотехника #семинар #МИРЭА #банда

Заметка на полях. Седьмая глава "Изучаем DDD". Моделирование фактора времени.

Что порадовало:
✔️Много кода. Псевдязык значительно облегчает понимание подходов.
✔️Хорошие пояснения к терминам. Ощущения запутанности - нет по прочтению.
✔️Хорошо раскрыт подход к проектированию основанный на событиях. Мне понятно.
✔️ЧАВО на тему "А чо так сложна? Давай сделаем попроще!" - мне кажется, это вообще во всех главах надо бы добавить.

Чего хотелось бы добавить или сделать лучше:
✔️ Я бы хотел посмотреть где-то более конкретные примеры и модели решений основанных на описываемый в этой главе. Схемки, обоснования, результаты применения. Поскольку здесь для всего связанного с Событиями Как Источником Данных приводится достаточно много аргументов за и ограничений, мне кажется важно больше практических примеров на эту тему было бы дать. Но может быть это от моей безграмотности (хотя книжка вроде бы для таких как я, не?)

Какие выводы:
✔️Пошли главы по большей части именно для программистов. А хотелось бы больше про системотехнический уровень. Ещё интересно было бы про программно-аппаратное проектирование почитать, насколько П.О.Пр применимо в этой сфере. Хотя похоже такой перенос это предмет для исследования.
✔️Вроде бы, у меня создаётся впечатление, что при заходе на ООП через П.О.Пр сложновато что-то новое изобрести.

Что дальше:
✔️Буду просить добавить примеров, и выносить такие штуки в арх этюды. Мне кажется - это непочатая тема для.

#книжное #DDD #ПОП #глава7 #Хононов

Заметка на полях. Образование в ИТ. DevOps.

Поскольку я нынче руководитель программы ДПП на цифровой кафедре МГТУ им. Баумана, некоторое время сижу и думаю, а чему именно и ради чего учить. По ходу дела сформировал некоторое количество рассуждений в отношении зачем учить и чему учить. Основаниями были мои личные рассуждения, память и заметки накопленные за период работы в этой сфере. Да, я в курсе, что DevOps - это культурный феномен. Но он выражается в конкретных ценностях, целевых показателях деятельности, применямых практиках, наборах навыков и знаниях. Поэтому я буду рассуждать о последних, по сути о том, что формирует профессию.

1. DevOps в настоящий момент всё больше про автоматизацию процессов жизненного цикла ИТ-систем. Не только и не столько "собрать, послать, прикрутить, посмотреть, пнуть" сколько все 15 (а то и больше) "технических" процессов жизненного цикла описанные в ISO/IEC/IEEE 15288-2015 (2023-го года стандарт пока не посмотрел). Поскольку ВНЕЗАПНО оказалось, что в циклы проверок нужно включать всякое сложное про безопасность, соответствие требованиям. Например оценку соответствия целевой ИТ-системы критериям качества исполнения бизнес-функций предприятия. А ещё внезапно там же появился мониторинг фитнесс-функций команд и автоматизация оценок "velocity" и подобных вещей. Встраивание в пайплайны интеграционных тестов, генерации наборов данных и в принципе всё остальное.

2. Прямым следствием из п.1 является необходимость для DevOps инженеров участия в формировании этих самых процессов, как внутренного "соисполнителя", для которого "команда" является "заказчиком". Т.е. DevOps инженер должен уметь выстраивать жизненные циклы подконтрольных ему систем. Начиная с выявления потребностей, поиска проблем, подбора технических решений и заканчивая менеджерскими практиками а-ля "управлять программой развития инструментов CI/CD в своей компании" (если такое вообще возможно).

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

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

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

В связи с чем имею желание провести семинар на тему: "Чему нам сейчас учить стремящихся в DevOps, чтобы в будущем с ними продуктивно было сотрудничать". В повестку хорошо бы включить обсуждение следующих тезисов:
- Расширение области ответственности DevOps инженеров и разделение труда. Риски и последствия.
- Что есть в мировой практике инженерной деятельности похожего, что мы могли бы перенести в область DevOps.
- Какая базовая подготовка должна быть у стремящегося в DevOps-инженеры?

#devops #рабочее #МГТУ #идейное

Заметка на полях. Управление конфигурациями продукта.

Мой личный интерес в конечных продуктах для "простых пользователей" всегда был ниже, чем в инструментах для кручения гаек. Мне лично всегда интереснее точить карандаши, чем рисовать гравюры. В связи с этим я заморочен на разных видах инструментов поддержки разработки. DevOps - это как раз то, где у меня больше всего интереса в работе. Но поскольку нужно хорошо изучить предмета работы я закапываюсь в достаточно большое количество разных тем.

Одна из таких - это управление конфигурациями продукта. Прекрасный пример продукта требующего управления конфигурацией - самолёт. Или автомобиль.

В современном варианте этот самый самолёт/автомобиль совокупность следующих вещей:
1. Платформы.
2. Вариантов групп "опций"/"фич" и т.п.
3. Различного, что позволяет платформу+фичи использовать в целевой среде.

Как правило вся петрушка с УК и нужна, когда есть поставка продукта в разные среды. В случае ИТ систем - эта штука прослеживается например: коробка+фичи+доработки. Т.е. прямая связь с процессами сборки,выпуска, доставки, мониторинга и получения обратной связи от экземпляров продукта.

А поскольку нынче идёт, и надеюсь будет идти импортозамещение, мне кажется стоит начать копать в эту тему поглубже. Я тут буду периодически постить всякое по теме: #управлениеконфигурацией.

#идейное #исследовать

Заметка на полях. Models and Methods of Software Configuration Management

В поисках того, что вообще есть на тему, решил начать с поиска статей. В качестве отправной точки попалась [статья]. Что лично меня подкупило:
✅ В качестве ключевого слова указан Model-driven approach
✅ Множество родных DevOps-у слов во введении.

Обсуждаемая проблема:
Как быстро и наименее болезненно получить достаточно формальный процесс выпуска версии продукта.

Что вынес полезного:
Корни сложностей при работе с управлением конфигурациями:
1. Мало кто знает, что такое "управление конфигурациями" кроме глубоко погружённых в сложные проекты.
2. Существующие инструменты как раз для сложных проекта, и внедрять их сходу - жесть.
3. В связи с быстротой изменения процессов и прочего один раз разработанные инструменты и сценарии нуждаются в постоянном сопровождении [1].
4. Инструменты позволяющие что-то моделировать слабо поддерживают процессы управления конфигурацией и слишком сложны или не применимы в общем случае [2].

Помимо этого можно отметить следующее:
1. Понятно, что управление конфигурацией, похоже, будет вотчиной девопсов. Или уже стало, но мы пока не заметили.
2. Можно говорить, что подходов к снаряду сделано достаточно много, и есть куда копать, прежде чем пытаться сходу решать проблемы.
3. Видно, что могут пригодиться знания CMMI и ITIL.
4. Придётся заниматься интеграцией множества тулов, а следовательно и моделей в них лежащих.

По содержательной части статьи:
К сожалению, статья оказалась не очень ценной, поскольку:
1. Авторы называют статью как обзорную, но не дают де-факто обзора технологий. А в качестве примеров ссылаются на собственные предыдущие работы.
2. Авторы попытались смоделировать техническое решение, без разбора "А где там собственно сложность, которую приходится решать" и "Как в общем виде выглядит процесс управления конфигурацией".

Вывод:
Нужно копать дальше, и походу придётся проблематику доставать из своей головы.

#идейное #управлениеконфигурацией #рабочее

Заметка на полях. Управление конфигурацией.

Наткнулся на цикл статей пол CM 12-ти летней давности. Интересно бы было ретроспективно рассмотреть.

Ссылки:
•Начало
•Опорные срезы
•Изменения
•Контроль версий
•Метрики и документация
•Средства контроля версий
•Книжки рекомендуемые автором (2010-й год)

Очевидно, что проблема старая, но почему-то я про неё вообще не слышу ничего в публичном поле. Как будто либо не забота архитектора, либо решённая проблема. Но последнее очевидно не так.

#управлениеконфигурацией #рабочее

Заметка на полях. Восьмая глава "Изучаем DDD". Архитектурные паттерны.

Что порадовало:
✔️Даётся набор конкретных инструментов.
✔️Сказано какова ценность применения паттернов.
✔️Как и обычно указаны границы применимости.

Чего хотелось бы добавить или сделать лучше:
✔️Мне, как человеку напрямую не разрабатывающему ПО главы 5-9 кажутся слабоинтересными. Да, понятны рассуждения, но конкретной практической применимости я пока для себя не вижу.
✔️Как мне кажется в восьмой главе много крутится вокруг CAP-теоремы, но при этом основные выборы между С, А, Р - не указаны. Наверное стоит про это рассказать больше.
✔️Мало уделено внимания аспектам вычислительной сложности (ресурсоёмкости) с другими подходами. Хотя может быть это тема другой книги.

Какие выводы:
✔️Сложно делать конкретные выводы, поскольку это не моя тема.

Что дальше:
✔️Читаем дальше. Копим обратную связь.

#книжное #DDD #ПОП #глава8 #Хононов