Начал читать "Предметро-ориентированное проектирование" Эванса.
Основная сложность программ сосредоточена в предметной области, а не в коде. Следует строить архитектуру приложения на основе модели предметной области.
#ddd
Основная сложность программ сосредоточена в предметной области, а не в коде. Следует строить архитектуру приложения на основе модели предметной области.
#ddd
Для построения надёжных приложений важно разрабатывать их итеративно и в тесном взаимодействии со специалистами предметной области (представителями бизнеса).
#ddd
#ddd
Модель должна строиться во взаимодействии разработчиков и представителей бизнеса. Нужно сесть и определить, что должна делать программа. В процессе следует вырабатывать общий язык, на котором будут формулироваться все штуки связанные с приложением.
Два важных момента:
+ Взаимодействие технических специалистов и представителей бизнеса.
+ Общий язык.
#ddd
Два важных момента:
+ Взаимодействие технических специалистов и представителей бизнеса.
+ Общий язык.
#ddd
Общий язык должен быть повсюду. Термины, их взаимосвязи. Он должен быть отражены в документации, коде, переписке и устном общении.
Если в коде мы называем управляющего магазином "Управляющий", значит такой же термин мы будем использовать обсуждая с заказчиком систему.
Этот язык не следует насаживать. Нужно вырабатывать его совместно. При этом, он может эволюционировать. И тогда нужно приводить все к новым терминам. Затраты не переименования класса — мелочь по сравнению с непониманием, возникающим из-за разных терминов.
#ddd
Если в коде мы называем управляющего магазином "Управляющий", значит такой же термин мы будем использовать обсуждая с заказчиком систему.
Этот язык не следует насаживать. Нужно вырабатывать его совместно. При этом, он может эволюционировать. И тогда нужно приводить все к новым терминам. Затраты не переименования класса — мелочь по сравнению с непониманием, возникающим из-за разных терминов.
#ddd
Нельзя отрывать модель от реализации. Придумали модель, но в коде она не используется? Значит она ничего не стоит.
Те, что думают над моделью должны писать код. Те, кто пишет код, должны думать над моделью.
Нельзя допускать до кода человека, не погруженного в предметную область.
#ddd
Те, что думают над моделью должны писать код. Те, кто пишет код, должны думать над моделью.
Нельзя допускать до кода человека, не погруженного в предметную область.
#ddd
Эванс предлагает строить приложения по многоуровневой архитектуре.
1. Представление (Presentation). Работа с внешним источником команд. Это может быть интерфейс пользователя, API. Тут только принимаем запрос и формируем ответ.
2. Операционный (Application). Тут занимаемся оркестрацией объектами доменной модели. Решаем как и куда их дёрнуть.
3. Предметной области (Domain). Вся логика работы приложения. Бизнес правила.
4. Инфраструктурный (Infrastructure). Обеспечение работы других слоев. Общение с базой данных, отправка уведомлений, загрузка файлов на удаленное хранилище.
При этом компоненты слоя могут зависеть только от компонентов находящихся в том же слое, или ниже. То есть Application не может зависеть от Interface, но может от Infrastructure.
#ddd
1. Представление (Presentation). Работа с внешним источником команд. Это может быть интерфейс пользователя, API. Тут только принимаем запрос и формируем ответ.
2. Операционный (Application). Тут занимаемся оркестрацией объектами доменной модели. Решаем как и куда их дёрнуть.
3. Предметной области (Domain). Вся логика работы приложения. Бизнес правила.
4. Инфраструктурный (Infrastructure). Обеспечение работы других слоев. Общение с базой данных, отправка уведомлений, загрузка файлов на удаленное хранилище.
При этом компоненты слоя могут зависеть только от компонентов находящихся в том же слое, или ниже. То есть Application не может зависеть от Interface, но может от Infrastructure.
#ddd
Вернёмся к Эвансу.
Слой предметной области представляет три типа объектов.
1. Сущности — эти объекты уникальные от рождения и до смерти. Например, в контексте банковской сферы, это клиент. Не важно, сменил он имя, пол или адрес. Нам важно сохранить его историю.
2. Объекты-значения — не уникальны, ценны только своим значением. В том же контексте, это могут быть адреса. Адрес однозначно характеризуется городом, улицей, домом. Если что-то из этого изменилось — это уже совсем новый адрес.
3. Сервисы. Кусочки логики не относящиеся к сущностям или объектам-значениям. Например, сервис выполнения транзакций. Он работает сразу с двумя счетами и хранит логику перевода средств с одного на другой.
#ddd
Слой предметной области представляет три типа объектов.
1. Сущности — эти объекты уникальные от рождения и до смерти. Например, в контексте банковской сферы, это клиент. Не важно, сменил он имя, пол или адрес. Нам важно сохранить его историю.
2. Объекты-значения — не уникальны, ценны только своим значением. В том же контексте, это могут быть адреса. Адрес однозначно характеризуется городом, улицей, домом. Если что-то из этого изменилось — это уже совсем новый адрес.
3. Сервисы. Кусочки логики не относящиеся к сущностям или объектам-значениям. Например, сервис выполнения транзакций. Он работает сразу с двумя счетами и хранит логику перевода средств с одного на другой.
#ddd
Управлять сущностями и вэлью-обжектами сложно. Потому часто несколько таких объектов объединяют в агрегат. Агрегат управляет всеми объектами внутри себя и наружу представляет только одну сущность. Она называется корневой.
Так как агрегаты сложно строить руками, часто используют фабрики для этого.
А для получения корневой сущности по какому-нибудь принципу — репозиторий.
#ddd
Так как агрегаты сложно строить руками, часто используют фабрики для этого.
А для получения корневой сущности по какому-нибудь принципу — репозиторий.
#ddd
Мудрость из книги
У созданного прототипа есть три ценности:
+ Клиент посмотрит на какое-то подобие системы и даст обратную связь.
+ Программисты, которым предстоит писать настоящую систему познакомятся с проблемой. Поймут ее на более глубоком уровне.
+ Программисты, которые пишут другие части системы (интерфейс, например) смогут начинать разработку, постепенно переходя от взаимодействия с прототипом к работе с настоящей системой.
Конспект книги Эрика Эванса "Предметро-ориентированное проектирование".
#ddd
У созданного прототипа есть три ценности:
+ Клиент посмотрит на какое-то подобие системы и даст обратную связь.
+ Программисты, которым предстоит писать настоящую систему познакомятся с проблемой. Поймут ее на более глубоком уровне.
+ Программисты, которые пишут другие части системы (интерфейс, например) смогут начинать разработку, постепенно переходя от взаимодействия с прототипом к работе с настоящей системой.
Конспект книги Эрика Эванса "Предметро-ориентированное проектирование".
#ddd
Мудрость из книги
Любой публичный интерфейс должен быть информативен. Если это интерфейс класса, то любой метод должен своим именем выражать, что он делает. Причем не как, а что.
Никогда не следует раскрывать детали реализации в интерфейсе.
Конспект книги Эрика Эванса "Предметро-ориентированное проектирование".
#ddd
Любой публичный интерфейс должен быть информативен. Если это интерфейс класса, то любой метод должен своим именем выражать, что он делает. Причем не как, а что.
Никогда не следует раскрывать детали реализации в интерфейсе.
Конспект книги Эрика Эванса "Предметро-ориентированное проектирование".
#ddd
Мудрость из книги
Все действия лучше разделить на "команды" и "запросы".
Запросы не могут изменить состояние приложения. Они только возвращают данные по каким-то критериям. Никаких побочных эффектов!
Команды изменяют состояние приложения. Но ничего не возвращают (иначе будет соблазн использовать их как запросы).
Это помогает контролировать сложность приложения.
Конспект книги Эрика Эванса "Предметро-ориентированное проектирование".
#ddd
Все действия лучше разделить на "команды" и "запросы".
Запросы не могут изменить состояние приложения. Они только возвращают данные по каким-то критериям. Никаких побочных эффектов!
Команды изменяют состояние приложения. Но ничего не возвращают (иначе будет соблазн использовать их как запросы).
Это помогает контролировать сложность приложения.
Конспект книги Эрика Эванса "Предметро-ориентированное проектирование".
#ddd
Мудрость из книги
Нельзя допускать, чтобы код у разных членов команды сильно отличался. На страже этого стоит непрерывная интеграция. Речь идёт не только, и не столько, о тестах и линтерах на CI-сервере. Куда важнее постоянно интегрировать модель предметной области. Искоренять дубликаты понятий, изучать домен глубже.
Конспект книги Эрика Эванса "Предметро-ориентированное проектирование".
#ddd
Нельзя допускать, чтобы код у разных членов команды сильно отличался. На страже этого стоит непрерывная интеграция. Речь идёт не только, и не столько, о тестах и линтерах на CI-сервере. Куда важнее постоянно интегрировать модель предметной области. Искоренять дубликаты понятий, изучать домен глубже.
Конспект книги Эрика Эванса "Предметро-ориентированное проектирование".
#ddd
Мудрость из книги
Последние главы были о сосуществовании новой системы с крутой моделью и какой-то другой.
Если вторая система очень старая и "грязная" можно ввести предохранительный уровень. Это место, в котором сконцентрировано общение новой и старой модели. Грязь не может проползти в новую систему, а старая система не вынуждена подстраиваться под новую.
Конспект книги Эрика Эванса "Предметро-ориентированное проектирование".
#ddd
Последние главы были о сосуществовании новой системы с крутой моделью и какой-то другой.
Если вторая система очень старая и "грязная" можно ввести предохранительный уровень. Это место, в котором сконцентрировано общение новой и старой модели. Грязь не может проползти в новую систему, а старая система не вынуждена подстраиваться под новую.
Конспект книги Эрика Эванса "Предметро-ориентированное проектирование".
#ddd
Нужная книга
Дочитал "Предметро-ориентированное проектирование" Эрика Эванса.
Думаю, через год следует перечитать и посмеяться над собой.
Книга монументальна. В ней изложен совершенно непривычный для меня способ построения приложений. В нем следует концентрироваться на бизнес-области заказчика, много работать со специалистами и думать головой.
Читать стоит, причем несколько раз, с некоторыми интервалами.
#ddd
Дочитал "Предметро-ориентированное проектирование" Эрика Эванса.
Думаю, через год следует перечитать и посмеяться над собой.
Книга монументальна. В ней изложен совершенно непривычный для меня способ построения приложений. В нем следует концентрироваться на бизнес-области заказчика, много работать со специалистами и думать головой.
Читать стоит, причем несколько раз, с некоторыми интервалами.
#ddd
Послушал очень хороший доклад про #ddd от Маджита Хаджиана.
Strategic Domain-Driven Design for Improving Flutter architecture
Доклад почти не привязан к Flutter, но отлично раскрывает практику применения DDD к клиентским приложениям. Уверен, что каждому разработчику интерфейсов стоит посмотреть запись.
Strategic Domain-Driven Design for Improving Flutter architecture
Доклад почти не привязан к Flutter, но отлично раскрывает практику применения DDD к клиентским приложениям. Уверен, что каждому разработчику интерфейсов стоит посмотреть запись.
Книга, которая сильнее других сказалась на моем профессиональном росте — Domain-Driven Design. #ddd перевернуло мой взгляд на разработку программ, на ценности которые они несут.
Я хочу, чтобы больше программистов следовало этой методологии, поэтому первый вебинар — «DDD в Node.js».
Три часа будем вместе делать небольшой сервис на Node.js, отвечу на вопросы. Всех участников добавлю в специальный чат, где можно будет продолжить обсуждение.
Вебинар пройдёт 18 апреля 2020 в 14.00 МСК.
До 4 апреля его можно купить за 1200 рублей, потом — за 1500.
Я хочу, чтобы больше программистов следовало этой методологии, поэтому первый вебинар — «DDD в Node.js».
Три часа будем вместе делать небольшой сервис на Node.js, отвечу на вопросы. Всех участников добавлю в специальный чат, где можно будет продолжить обсуждение.
Вебинар пройдёт 18 апреля 2020 в 14.00 МСК.
До 4 апреля его можно купить за 1200 рублей, потом — за 1500.
Что можно узнать о Domain Driven Design за 10 минут?
Очень краткая вводная статья по DDD. Стоит прочитать, чтобы понять основные концепции. Обратите внимание, там внизу много хороших ссылок.
Статья
Strategic Domain Driven Design for Improving Flutter architecture
Доклад про DDD в Flutter. На самом деле, он почти не связан с конкретной технологией, а скорее презентует общие подходы.
Запись, слайды
#ddd
Очень краткая вводная статья по DDD. Стоит прочитать, чтобы понять основные концепции. Обратите внимание, там внизу много хороших ссылок.
Статья
Strategic Domain Driven Design for Improving Flutter architecture
Доклад про DDD в Flutter. На самом деле, он почти не связан с конкретной технологией, а скорее презентует общие подходы.
Запись, слайды
#ddd