Артём Антоненко, Application architect in XLNTech выступил на конференции CODEiD – PHP Odessa Conf #4 с темой «Domain Driven Design». «Очень много разработчиков, выбравших PHP основным языком программирования, получили свои знания по архитектуре из инструкций для фреймворков. Немногие обратились к источникам, которые написаны для (с помощью) Java, C++ и других языков. Язык PHP уже давно перестал быть уделом домохозяек и перешел в инструменты для разработки enterprise приложений. Но как писать такой код, который будет понятен и легко расширяем через год, два и более? Как подготовить монолит к разделению на микросервисы? Как выстроить эффективное взаимодействие со stakeholders? На эти вопросы отвечает предметно-ориентироанние программирование.» CODEiD – это всеукраинское сообщество PHP-разработчиков.Наша цель — создать сильное сообщество всех, кто увлечен PHP-разработкой, и принимать в нашем уютном приморском городе коллег со всей Украины и мира.

1. Domain driven design
Артем Антоненко

2. 2 слайд из 39
Артем Антоненко
Engineering manager/Application architect at
XLNTech (Remit )
Опыт в менеджменте более 9 лет.
Консультант в сфере реинжиниринга бизнес-
процессов.
Более 6 лет в девелопменте.

3. Coding vs
Development
3 слайд из 39

4. Следование
рецептам
4 слайд из 39

5. Если что-то
пошло не по
сценарию
5 слайд из 39

6. Sophia Phronesis
6 слайд из 39

7. Framework
7 слайд из 39

8. Как выглядит
классический
проект?
8 слайд из 39

9. Acceptance criteria?
9 слайд из 39

10. 2 slides
Smart UI

11. Client - Server
Internet
11 слайд из 39

12. Then there’s the matter of what comes
under the term “business logic.”
I find this a curious term because there
are few things that are less logical than
business logic. («Patterns of Enterprise
Application Architecture»)
12 слайд из 39

13. Отказ от четкого выделения предметной
области при определенных условиях может
обернуться катастрофой. Если задача
предстоит сложная и принято решение
следовать принципам ПРОЕКТИРОВАНИЯ ПО
МОДЕЛИ (MODEL-DRIVEN DESIGN), то
стисните зубы, пригласите нужных
специалистов и избегайте
ИНТЕЛЛЕКТУАЛЬНОГО ИНТЕРФЕЙСА
(SMART UI).
Эрик Эванс
13 слайд из 39

14. Зачем DDD?

15. Джеймс Клерк Максвелл, "Трактат об
электричестве и магнетизме" James Clerk Maxwell,
А Treatise оп Electricity and Magnetism), 1873 г.
Эти четыре уравнения, вместе с определениями
понятий и лежащими в их основе математическим
аппаратом, описывают всю классическую теорию
электромагнетизма XIX в.
Зачем DDD? Упрощение сложных систем.
15 слайд из 39

16. Зачем DDD? Выделение и совершенствование
уникального торгового предложения
16 слайд из 39

17. Зачем DDD? Описание бизнес-процесса
17 слайд из 39

18. Зачем DDD? Низкий шанс появления “тайных знаний”
18 слайд из 39

19. Зачем DDD? Избавление от лишней документации
Customer BA SA Developer Tester
?! ?!
19 слайд из 39

20. Основные понятия.

21. Основные понятия. Единый язык
Domain expert
Analyst Developer
Developer
Ubiquitous
Language
Application
code
Test
code
Specs and
documentation
Whiteboard
discussions
21 слайд из 39

22. Основные понятия. Ограниченный контекст
Контекст
Граница, в
пределах которой
понятия
единого языка
имеют вполне
конкретное
значение.
Ordering context Supplier context
Order
Customer
Product
Vendor
Order
Invoice
22 слайд из 39

23. Основные понятия. Смысловое ядро
Смысловое ядро
Подобласть,
имеющая
первостепенное
значение для
организации.
Стратегия бизнеса
строится вокруг
смыслового ядра.
23 слайд из 39

24. Основные понятия. Карта контекстов
Заказ товаров
Сторонняя ERP
Модуль лояльности
Пользователи Shared kernel
ACL
Partnership
Модуль рекламы
Customer-supplier
Складской сервис
Conformist
24 слайд из 39

25. Основные понятия. Предметная область
Предметная
область
это то, что делает
организация, и
среда, в которой
она это делает.
Часто состоит из
предметных
подобластей.
Purchase
planning
Warehouse
context
Core
domain
Purchase
context
Distribution
context
Logistic
context
25 слайд из 39

26. И все же - что такое доменная модель?

27. Может, это она?
27 слайд из 39

28. Проекция Мерка́тора
Проекция Меркатора оказалась
весьма удобной для нужд
мореходства, особенно в
старые времена. Объясняется
это тем, что траектория
движения корабля, идущего
под одним и тем же румбом к
меридиану (то есть с
неизменным положением
стрелки компаса относительно
шкалы) изображается прямой
линией на карте в проекции
Меркатора.
Википедия
28 слайд из 39

29. Имплементация

30. Слоевая
архитектура
30 слайд из 39

31. RestaurantModule
Restaurant
RestaurantDbMapper
RestaurantService
RestaurantBuilder
31 слайд из 39

32. RestaurantContext
Restaurant
Attribute
Module
Location
Module
Restaurant
Waiter
Module
Restaurant
Module
32 слайд из 39

33. MenuContext
MenuContract
StorageContext
StorageContract
RestaurantContextOrderContext
OrderContract RestaurantContract
33 слайд из 39

34. 2 slides
В книге Эрика Эванса (Eric Evans) Domain-Driven Design
(Addison-Wesley) основное внимание уделялось
способам создания систем, моделирующих реально
существующие области..
Если нужна информация из ограниченного контекста
или нужно сделать запросы на какие-либо действия
внутри ограниченного контекста, происходит обмен
данными с его четко обозначенной границей с помощью
моделей. В своей книге Эванс использовал аналогию с
клетками: «Клетки могут существовать благодаря своим
мембранам, определяющим, что попадает внутрь, что
выходит наружу и что именно может через них
проходить».
Идеи, представленные Эриком Эвансом в книге
Domain-Driven Design, весьма полезны при поиске
разумных границ наших сервисов, и мы пока …

35. MenuContext StorageContext
RestaurantContextOrderContext
OrderContext RestaurantContext
MenuContext StorageContext
35 слайд из 39

36. https://github.com/Antonyan/ddd-skeleton
36 слайд из 39

37. Холивар

38. EfforttoEnhance
Complexity of Domain Logic?
2 hours to be clear about
Transaction script
Domain model
Table
Module
38 слайд из 39

39. Q & A
antonenko.artem@gmail.com