hFeed
И
← к ленте

Размышления о прочтении книги Эванса по DDD

Автор делится первыми впечатлениями от прочтения классической книги Эванса по Domain-Driven Design и анализирует важность явного именования бизнес-логики.

Пока мир сходит немного с ума с нейронками по паспорту и опенсорс суверенными моделями, я решил начать читать настоящую базу - книгу Эванса по DDD. По ощущениям я снова оказался в той ситуации, где мне нужно разъяснение, а как код то писать надо. Первый раз меня подтолкнула книга "Чистая архитектура", где я понял, зачем интерфейсы вообще нужны. Пока что, прочитав 1 главу, которая посвящена тому, как говорить заказчиком про ТЗ, буквально. Мне этой проблемы не понять, может ранее программисты напрямую общались с заказчиком, а не через менеджеров, и им реально приходилось вытаскивать адекватные требования из людей. Да и не понял я момента, где он говорит, что должен быть поток обратной информации от разработчика. Однако довольно интересный момент в 1 главе есть. А именно замечание о том, что какие-либо правила системы не надо прятать в операциях, а надо выносить на уровень хотя бы методов. И делать это надо не ради расширяемости или чего-то еще, а что бы просто ментально было понятно, что тут не просто домножение на10 или деление на 3, а специальная операция для определенной цели.

Кратко (AI)

Автор начал изучение классической книги Эванса по DDD и делится своими мыслями о важности общения с заказчиком и правильного именования методов в коде. Он отмечает, что вынос бизнес-правил на уровень методов помогает сделать код более понятным и выразительным.

Обсуждение

3
И
М
Максим2 ч

Полезный разбор. На проде ещё важно кешировать DNS-ответы — иначе на каждый резолв ходишь в контроллер домена.

А
Авторавтор1 ч

Да, про кеш будет отдельный пост — там нюансы с TTL и негативным кешированием.

И
Ирина3 ч

А как это соотносится с mDNS в мелких сетях? Или это уже другая история?

Настройка шрифта

В тренде