Удивительно, но мне до сих пор не напихали за то, что отвечая на вопрос про серверлесс я по факту говорил про nocode.
Интересно, это потому что меня так уважают или тупо уже некто не слушает, что я там бубню?

Михаил сгенерировал Хакера в Bing, я подхватил эстафету и сделал хакера в Шедеврум

На субботнем стриме просили книги по DDD, я уже говорил, что существует всего три книги, которые разбирают вопрос во всех деталях:

1. Вернон В. "Реализация методов предметно-ориентированного проектирования"
2. Эванс Э. Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем
3. Вернон В. Предметно-ориентированное проектирование. Самое важное

Как справочник лучше всего последний вариант (в стриме показывал его).

Продолжаю искать красивый код для анализа. Интересно найти что-то "боевое", построенное по классике DDD, но пока нахожу только примеры сомнительного качества.
Например, https://github.com/asc-lab/better-code-with-ddd вроде как сравнивает обычный слоеный монолит, с ддд-ым монолитом. Наверное нравится должен больше ДДД-ый вариант, но че-то вообще не нравится.

Поделитесь ссылкой на гитхаб репо с хорошим ДДД "боевым", а не высосанным из пальца примером.

Про логирование

Заметил, что если архитектурных примеров на гитхабе полно, то примеров с грамотным логированием еще надо поискать.

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

Считается, что потом в реальных проектах их этому научат, но те кто читал логи разных интерпрайзов знает, что нет, не научат.

Элементарный пример - guid, который в логах один из основных источников информации о сущностях, что мешает снабдить его человекопонятным префиксом? Сколько человеческих нервов можно было бы сэкономить благодаря этому. Но нет, всегда голый uuidV4 - наше все.

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

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

Вывод: учитесь писать логи, господа. Учитесь писать логи...

Проектирование WebAPI обычно не вызывает никаких проблем, пока не возникает требование унификации.

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

Если хочется понять что это за правила такие, по которым api строится, рекомендую вот этот видос https://www.youtube.com/live/KSBed4yyoDM?feature=share

Важно! я не уверен, что завтра буду делать стрим, сильно зависит от того соберем ли интересные темы. В любом случае, если даже стрим будет, то это последний стрим этого сезона, до сентября стримов не будет. Поэтому запускаю сбор тем на субботний стрим с учетом оговорки выше:

1. ЗЭН - пишите в комментариях вопросы (буду выбирать самые популярные или которые понравятся мне) - ответ будет в субботнем стриме

2. Ревью кода и проектов - может быть вам интересно узнать мое мнение по вашему репозиторию (можно от фрагментов кода, до своих проекто) на github - тогда можно написать ссылку в комментариях и примерно чего вы ожидаете, буду выбирать на свое усмотрение и желание и в субботу на стриме будет обзор

3. Как всегда все что будет на https://donate.s0er.ru буду рассматривать в обязательном порядке (если по АйТи, все провакационные вопросы и подколы не рассматриваю).

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

У Димы подписчик задаёт вопрос о том, что ему скучно на работе, потому что ему не хватает задач. Подозреваю, что проблема а том, что чувак хочет делать только интересные ему задачи и не заниматься рутиной, которой у среднего разраба обычно 80%.

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

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

https://t.me/seniorsoftwarevlogger/1287

Чем отличается "разработка решения" от "реализации решения"?

Поясню на примере, вот есть у нас задача "Решение квадратного уравнения". Оно будет состоять из двух этапов "разработка" и "реализация"

Разработка решения выглядит так: "Я посчитаю дискриминант (по формуле D = b^2 - 4ac), затем посчитают по формуле корней (+-b - sqrt(D)) / 2a значения х1,х2"

Реализация решения - это уже готовый код, но можно описать в общем виде: "Я возьму Матлаб, создам новый документ, в нем заведу общие переменны a, b, c для квадратного уравнения виде ax^2 + bx + c, далее рассчитаю D, затем рассчитаю x1, x2"

Т.е. разработка решения - это описание общей логики (алгоритма) решения, а реализация - это конечное решение, которое решает поставленную задачу.

Проблема в том, что когда надо "Разработать решение", очень часто вместо разработки делается общее описание реализации, которое по сути тот же код, но на псевдоязыке. Это неправильно, нужно развивать алгоритмическое мышление и отделать "логику" от "реализации".

1 июля повторим?

г. Сочи, ул. Войкова 4В "Мой кофе" в субботу 1 июля в 10:00
Сходка настоящих соеров - только хардкор, только программирование, только те кто реально любит наше дело. 😎

Есть у нас группа для общения ютуберов между собой, называется "круги на поля IT" (https://t.me/itkrugi), мы там обычно просто стебемся друг над другом, выкладываем кружки из жизни и в целом бездарно тратим ресурсы интернета.

Но сегодня получился конструктивный разговор, который многим может быть интересен. Все началось с вброса ExtreamCode мол если бы кому-то были важны оптимизации, то Bool бы занимал один бит. Понятно, что любой соер в этот момент делает "рука лицо" и ворчит про "и эти люди говорят, что образование не нужно". Потому что для юзеров высокоуровневых языков, которые видят все через абстракции над абстракциями, кажется: "ну а чо? выделим один бит и делов-то, это бесплатно и очень просто".

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

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

Напоминаю, что завтра в 10 утра в Сочи состоится грандиозная встреча соеров )

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

Вчера пообщались про школу №21 от Сбера. Основная фишка их обучения - отсутствие наставников, вместо этого каждый оценивает каждого (peer-to-peer). В процессе обсуждения приши к мысли, что процесс их обучения очень похож на то, что мы делаем в Naris. Например, у нас принцип peer-to-peer называется devs2devs, который гласит что сами участники делают ревью кода других участников.

У нас наставничество не совсем исключено, но сведено к минимуму, по сути у нас так же используется принцип "равный среди равных" и в рамках ревью нужно не просто высказать свое мнение, но и конструктивно аргументировать. Если компетенция команды в школе 21 ограничена уровнем учеников, которые в массе своей - джуны, то у нас компетенция ограничена людьми уровнем мидлов, которые часто приходят в проект. Мне кажется, что это куда лучше, когда действующие разрабы общаются между собой (поэтому собственно devs2devs, а не peer-to-peer).

Еще одно отличие Naris и школы 21 в том, что мы делаем один проект, но по всем правилам разработки. Т.е. структура работы ничем не отличается от хороших "боевых" команд, которые используют современные практики программирования.

Почему я вдруг решил вспомнить этот разговор и сравнить Naris и школу 21? Для меня это подтверждение моих мыслей о том как должно быть выстроено обучение разработчиков, которых нужно быстро ввести в специальность. Идея объединить людей вокруг проекта и делать практические вещи находит поддержку в очень крутых компаниях таких как Сбер или Хуавей. А это в свою очередь говорит о том, что путь выбран правильно и нужно продолжать движение в Naris.

DDD основное, что нужно помнить

В предметно ориентированном дизайне задачу построения архитектуры приложения можно разделить на две части "Стратегическую" и "Тактическую".

Стратегия

Определяется решением следующих вопросов:

- Выделением общего языка
- Созданием пользовательских историй
- Выделение домена приложения

При этом для архитектур с централизованным хранилищем данных DDD чаще бывает излишним, чем полезным, DDD стоит рассматривать если у вас минимум 30-40 пользовательских историй.

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

Тактика

Включает в себя реализацию шаблонов для организации объектной модели приложения. В первую очередь выделяются слои приложения (от внутреннего к внешнему):

- Entities, Value objects, Domain Events, Aggregates
- Repositores, Domain Services
- Application services
- UI

Aggregate

Агрегаты - это абстрактное понятие, которое на диаграммах можно представить как "границу" всех сущностей (entities) и объектов значений (value objects), а в коде агрегат представлены "корнем агрегата", который как правило является сущностью, включающей в себя другие сущности.

Value Object vs Entity

Чтобы лучше понять когда что создавать помните:

- идентификация сущности делается по Id, value object идентифицируется всеми своими полями
- сущность имеет маскимально длинный жизненный цикл, объекты значения наоборот имеют очень короткий жизненный цикл
- сущности могут изменять свой стейт (спорно, но в целом так), объекты значения только создаваться новые, изменять старые не принято
- логика в объектах значениях обычно простая (объект делается "легким"), в отличии от сущностей


Domain Service

Чаще всего в доменные сервисы размещается общая логика, которую сложно связать с сущностями. Обычно доменных сервисов стараются много не создавать.

Репозиторий

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

Репозиторий - "один ко многим", может включать логику массовых операций.
Сущность - "один к одному", включает бизнес-логику и стейт.


#DDD #знания #теория

У Вернона стратегия включает: единый язык, предметная область, предметная подобласть, смысловое ядро, ограниченный контекст, карта контекстов.

Мне стоило пояснить, что в "домен приложения" входит карта контекстов и предметная область.

Хорошее дополнение.

#DDD #теория