Ребята запускаю сбор тем на субботний стрим:

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

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

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

Завтра хочу на стриме посмотреть код по анемичным моделям Хорикова. Если забуду, то нужен ответственный человек, который напомнит ))))

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

Удивительно, но мне до сих пор не напихали за то, что отвечая на вопрос про серверлесс я по факту говорил про 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://news.1rj.ru/str/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://news.1rj.ru/str/itkrugi), мы там обычно просто стебемся друг над другом, выкладываем кружки из жизни и в целом бездарно тратим ресурсы интернета.

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

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

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

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

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

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 #теория