Дмитрий Павлов, Антон Бевзюк, Domain Driven Design. Как писать простой код для сложных систем?
•Download as PPTX, PDF•
1 like•890 views
Нельзя просто так взять и написать простой код для сложной системы. Сколько бы мы не продумывали дизайн, наша стройная объектная модель начинает рушиться о суровую реальность требований. Через пару месяцев мы получаем множество неповоротливых объектов с набором полей под все сценарии использования. А ведь, еще вчера код был простой и понятный, архитектура стройна и без костылей. Откуда берется сложность? Как с ней бороться? Или это наш программистский крест? В мастер классе мы разберемся, как Domain Driven Design помогает разрабатывать объектную модель для сложных систем. Почему лучше иметь несколько контекстов использования классов? Почему 2-3 объекта для одной и той же бизнес-сущности это нормально? Почему важно говорить с бизнесом на едином языке и как явно выражать это в коде? Осторожно, техническая сессия, много кода, боли и холиваров.
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (6)
Similar to Дмитрий Павлов, Антон Бевзюк, Domain Driven Design. Как писать простой код для сложных систем?
Similar to Дмитрий Павлов, Антон Бевзюк, Domain Driven Design. Как писать простой код для сложных систем? (20)
More from ScrumTrek
More from ScrumTrek (20)
Дмитрий Павлов, Антон Бевзюк, Domain Driven Design. Как писать простой код для сложных систем?
- 1. Domain Driven Design. Как писать простой код для сложных систем? Дмитрий Павлов Антон Бевзюк SmartStepGroup
- 2. SmartStepGroup Внедряем инженерные практики XP Ставим процессы
- 8. Когда покупатель оплатил заказ, мы отправим ему email с подтверждением
- 9. UPDATE tbl_user SET status = 18 WHERE type = 3 AND id = …
- 11. Ubiquitous Language DeleteAllLines CancelOrder SetStatus(Status.Approved) Approve CreateUser EnrollCustomer Customer.Address = new Address() Customer.RelocateTo(new Address())
- 24. Преимущества Экономим время на «переводе» Не теряем информацию Понятный для всех код
- 25. Преимущества Код мутирует вместе с бизнесом, вместо костылей Меньше документации Меньше ошибок
- 27. Сложность Мудрое руководство Отдел продаж Отдел закупок Аналитики Производство
- 28. Bounded Context
- 34. Context Map
- 35. Не все большие системы будут хорошо спроектированы http://www.laputan.org/mud
- 39. Борьба со сложностью Доменная модель != Объектная модель Вездесущий язык Домены и поддомены вместо единой модели Context Map
- 40. Ссылки Тренинг SmartStepGroup по DDD http://www.amazon.com/Domain-Driven-Design-Tackling- Complexity-Software/dp/0321125215 DDD misconceptions - Dino Esposito (SA2014) How You Can Architect and Develop Enterprise Mission-Critical Applications with Domain-Driven Design - Vaughn Vernon Eric Evans: What I've learned about DDD since the book was published DDD & Microservices: At Last, Some Boundaries! • Eric Evans Pluralsight - Domain-Driven Design in Practice - Vladimir Khorikov
- 41. Спасибо за внимание! Дмитрий Павлов dmitry@smartstepgroup.com Антон Бевзюк anton@smartstepgroup.com www.smartstepgroup.com blog.smartstepgroup.com twitter.com/SmartStepGroup
Editor's Notes
- - Книга 10 лет назад - Сложность + Факт: ООП не решило проблему сложности - Сменился фокус + Главное - это не ValueTypes, Entities, ... + Главное - UL и BC - Раскрыть название DDD
- - Persistence ignorance + Традиция - наоборот, solid DB Привычка проектировать снизу вверх Привычное ООО моделирование (объекты - отношения) слишком общее DDD вводит более специфичные строительные блоки: Value object, Entity, Service, Repository, Factory Новый ББ – Domain Event
- - Persistence ignorance + Традиция - наоборот, solid DB Привычка проектировать снизу вверх Привычное ООО моделирование (объекты - отношения) слишком общее DDD вводит более специфичные строительные блоки: Value object, Entity, Service, Repository, Factory Новый ББ – Domain Event
- Язык, позволяющий разработчикам и Заказчику общаться, избегая ошибочного толкования («испорченный телефон»)
- Язык, позволяющий разработчикам и Заказчику общаться, избегая ошибочного толкования («испорченный телефон»)
- - Мы часто жалуемся на изменяющиеся требования + Одна из причин – недопонимание - Звонок заказчика - Мы строим "правильную" модель, а не соответствующую бизнесу -> сложность
- Одно и то же название у разных сущностей Смысловой шум Типичная ошибка - создание единой объектной модели Абстрагирование -> сложность Система из подсистем, домен из поддоменов Отделы Пересечение невидимой границы Свой язык Своя архитектура
- Big Ball of Mud
- Partner Взаимная зависимость Кооперация Могу ли я успешно зарелизить, если они не зарелизят?
- Misroservices