diff --git a/ru-RU/Chapter1/Getting-Started-with-Domain-Driven-Design.md b/ru-RU/Chapter1/Getting-Started-with-Domain-Driven-Design.md index 0cc1659..0c02f42 100644 --- a/ru-RU/Chapter1/Getting-Started-with-Domain-Driven-Design.md +++ b/ru-RU/Chapter1/Getting-Started-with-Domain-Driven-Design.md @@ -1,191 +1,193 @@ Глава 1. Начало работы с DDD. == -Так откуда весь шум? Если вы уже читали книги на эту тему за авторствами Vaughn Vernon и Eric Evans, -вы, вероятно, знакомы с тем, что мы собираемся рассказать, поскольку мы в значительной степени заимствуем их определения -и объяснения. DDD - это подход, который позволяет нам преуспеть в понимании и построении моделей программных продуктов. -Он предоставляет нам инструменты стратегического и тактического моделирования для разработки высококачественного программного -обеспечения, соотвествующего нашим бизнес-целям. ->Основная цель этой книги - показать примеры тактических шаблонов DDD используя PHP. Если вы хотите -больше узнать о стратегических шаблонах и о DDD впринцепе, вам следует прочитать книги за авторством -Vaughn Vernon и Eric Evans. - -Что очень важно, DDD не связан с технологиями. Вместо этого речь идет о развитии знаний о бизнесе и испльзовании технологий -для обеспечения ценности. Только когда вы сможете понять бизнесс, в котором работает ваша компания -, вы сможете участвовать в процессе создания модели программного обеспечения пораждая Единый Язык (Ubiquitous Language). +Так откуда весь шум? Если вы уже читали книги на эту тему за авторствами Vaughn Vernon и Eric Evans, вы, вероятно, знакомы с тем, что мы собираемся рассказать, поскольку мы в значительной степени заимствуем их определения и объяснения. DDD - это подход, который позволяет нам преуспеть в понимании и построении моделей программных продуктов. Он предоставляет нам инструменты стратегического и тактического моделирования для разработки высококачественного программного +обеспечения, соответcтвующего нашим бизнес-целям. + +
+ +> Основная цель этой книги - показать примеры тактических шаблонов DDD используя PHP. Если вы хотите больше узнать о стратегических шаблонах и о DDD в принципе, вам следует прочитать книги за авторством Vaughn Vernon и Eric Evans. + +
+ +Что очень важно, DDD не связан с технологиями. Вместо этого речь идет о развитии знаний о бизнесе и использовании технологий для обеспечения ценности. Только когда вы сможете понять бизнес, в котором работает ваша компания, вы сможете участвовать в процессе создания модели программного обеспечения порождая Единый Язык (Ubiquitous Language). + +
## Почему DDD так важен -Програмнное обеспечение это не только код. Код редко является конечной целью вашей работы. Код это только средства решения -бизнесс-задач. Так почему код должен быть на языке отличном от языка бизнесса? DDD подчеркивает что код и бизнесс должны -говорить на одном языке. Когда барьер преодален, нет необходимости в переводе или утомительной синхронизации, информация не -потеряется. Каждый участник влияет на Бизнесс-Домен, не только разработчики.Получающееся программное обеспечение - + +Программное обеспечение это не только код. Код редко является конечной целью вашей работы. Код это только средства решения бизнес задач. Так почему код должен быть на языке отличном от языка бизнеса? DDD подчеркивает что код и бизнес должны говорить на одном языке. Когда барьер преодолен, нет необходимости в переводе или утомительной синхронизации, информация не потеряется. Каждый участник влияет на Бизнесс-Домен, не только разработчики. Получающееся программное обеспечение - единственная правда для общего языка. -DDD также обеспечивает основу для стратегического и тактического моделирования. Стратегическое проектирование позволяет точно -определить наиболее важные области разрабоки на основе бизнес-ценностей. Тактическо -моделироване нужно для построения работающей Доменой Модели с использование проверянных в бою +DDD также обеспечивает основу для стратегического и тактического моделирования. Стратегическое проектирование позволяет точно определить наиболее важные области разработки на основе бизнес-ценностей. Тактическое моделирование нужно для построения работающей Доменной Модели с использование проверенных в бою строительных блоков и шаблонов. +
+ ## Три столпа DDD + Domain-Driven Design это подход к разработке программного обеспечения, который сфокусирован на трёх основных принципах: -1. **Единный Язык (Ubiquitous Language)**: Эксперты предметной области (Domain Experts) и разработчики программного обеспечения работают вместе, -чтобы создать общий язык для разрабатываемых бизнесс-сфер. Тут не может быть противопоставления, это единная команда. -Разработка программного обеспечения это инвестиция в бизнес, а не просто статья расходов. Усилия, прилогаемые к созданию -Единого Языка (Ubiquitous Language), помогают распространить глубокое понимание Домена (Domain) среди всех членов команды. -2. **Стратегическое моделирование (Strategic Design)**: DDD направлен на стратегию управления бизнесом, а не только на технические -аспекты его работы. Это помогает определить внутренние отношения и системы обратной связи раннего предупреждения. -С технической стороны, стратегический дизайн защищает каждую бизнес-услугу, обеспечивая мотивацию для достижения -сервис-ориентированной архитектуры. -3. **Тактическое моделирование (Tactical Design)**: DDD предоставляет инструменты и строительные блоки для итеративной разработки -программного обеспечения. Инструменты тактического моделирования позволяют создать программное -обеспечение, которое не только предельно корректно, но и является тестируемым и менее подверженым ошибкам. + +1. **Единный Язык (Ubiquitous Language):** + Эксперты предметной области (Domain Experts) и разработчики программного обеспечения работают вместе, чтобы создать общий язык для разрабатываемых бизнес-сфер. Тут не может быть противопоставления, это единая команда. Разработка программного обеспечения это инвестиция в бизнес, а не просто статья расходов. Усилия, прилагаемые к созданию Единого Языка (Ubiquitous Language), помогают распространить глубокое понимание Домена (Domain) среди всех членов команды. + +2. **Стратегическое моделирование (Strategic Design):** + DDD направлен на стратегию управления бизнесом, а не только на технические аспекты его работы. Это помогает определить внутренние отношения и системы обратной связи раннего предупреждения. С технической стороны, стратегический дизайн защищает каждую бизнес-услугу, обеспечивая мотивацию для достижения + сервис-ориентированной архитектуры. + +3. **Тактическое моделирование (Tactical Design):** + DDD предоставляет инструменты и строительные блоки для итеративной разработки + программного обеспечения. Инструменты тактического моделирования позволяют создать программное обеспечение, которое не только предельно корректно, но и является тестируемым и менее подверженным ошибкам. + +
+ ### Единый язык (Ubiquitous Language) Наряду с темой главы 12 "Интеграция Ограниченного Контекста (Bounded Contexts)", Единый Язык (Ubiquitous Language) является одной из главных сильных сторон DDD. ->Пока будем рассматривать Ограниченный Контекст как концептуальную границу вокруг системы. Единый язык внутри этой границы -имеет особое концептуальное значение. Концепции и определения вне этой границы могут иметь иные значения. + +
+ +> Пока будем рассматривать Ограниченный Контекст как концептуальную границу вокруг системы. Единый язык внутри этой границы имеет особое концептуальное значение. Концепции и определения вне этой границы могут иметь иные значения. +> +
Итак, как найти, изучить и запечатлеть этот особый язык, следующие подсказки помогут вам в этом: -+ Определить ключевые бизнесс-процессы, их входы и выходы. -+ Создайть глосарий терминов и определений. ++ Определить ключевые бизнес-процессы, их входы и выходы. + ++ Создайте глоссарий терминов и определений. + + Определить важные концепции программного обеспечения с хорошей документацией. -+ Обменивайтесь этими знаний со всеми членами команды (Разработчиками и Экспертами Предметной Области) -С распростронением DDD, появились новые методы улучшающие и упрощающие процесс создания -Единого Языка (Ubiquitous Language). Самый важный и наболее часто используемый метод это Событийный штурм (Event Storming). + ++ Обменивайтесь этими знаниями со всеми членами команды (Разработчиками и Экспертами Предметной Области). + +С распространением DDD, появились новые методы улучшающие и упрощающие процесс создания Единого Языка (Ubiquitous Language). Самый важный и наиболее часто используемый метод это Событийный штурм (Event Storming). + +
#### Событийный Штурм (Event Storming) -Alberto Brandolini рассказывает о Событийном Штурме и его преимущствах в своем блоги, и он делает это гораздо лаконичней -чем это могли бы сделать мы. Событийный штурм (Event Storming) - это формат семина для быстрого моделировани сложных бизнес-доменов: -+ Это мощно: подход позволил мне и многим практикующим его специалистам создать всеобъемлищую -модель полго бизнес-потока за часы, а не недели. -+ Это доступно: вся идея состоит в том, чтобы собрать людей у которых есть вопросы и людей у которых есть на них ответы, -в одно месте и совместно построить модель. -+ Это эффективно: результирующая модель идеально соотвествует стилю реализации DDD (особено использую подход Event Sourcing) - и позволяет быстро обределять Контексты и Агрегаты (Aggregate boundaries). -+ Это просто: утра-простые заметки. Без сложных UML диаграмм, которые могут отвлечь участников от сути дискуссии. +Alberto Brandolini рассказывает о Событийном Штурме и его преимуществах в своем блоги, и он делает это гораздо лаконичней чем это могли бы сделать мы. + +Событийный штурм (Event Storming) - это формат семинара для быстрого моделирования сложных бизнес-доменов: ++ Это мощно: подход позволил мне и многим практикующим его специалистам создать всеобъемлющую модель полного бизнес-потока за часы, а не недели. + ++ Это доступно: вся идея состоит в том, чтобы собрать людей у которых есть вопросы и людей у которых есть на них ответы, в одно месте и совместно построить модель. + ++ Это эффективно: результирующая модель идеально соотвествует стилю реализации DDD (особено использую подход Event Sourcing) и позволяет быстро обределять Контексты и Агрегаты (Aggregate boundaries). + ++ Это просто: ультра-простые заметки. Без сложных UML диаграмм, которые могут отвлечь участников от сути дискуссии. + + Это захватывающе: я всегда прекрасно проводил время организуя семинары. Люди заражаются энергией и делают больше, чем ожидали от себя. -В ходи работы возникают правильные вопросы, и формируется правильная атмосфера. +В ходе работы возникают правильные вопросы, и формируется правильная атмосфера. Если вы желаете больше узнать о Событийном Штурме, ознакомьтесь с книгой Brandolini, Introducing EventStorming. +
+ ## Определение DDD -DDD это не серебрянная пуля; как и все в програмном обеспечении, всё зависит от контекста. -Старайтесь использовать этот подход чтобы упростить ваш Домен (Domain), а не добавляйте сложности. -Если разрабатываемое вами приложение ориентировано на работу с данными и ваши сценарии в основном подразумевают CRUD -операции (создание, чтение, обновление, удаление), то вам не нужен DDD. Вам всего лишь нужен интерфейс манипуляцией данными в -вашей хранилище. +DDD это не серебряная пуля, как и все в программном обеспечении, всё зависит от контекста. Старайтесь использовать этот подход чтобы упростить ваш Домен (Domain), а не добавляйте сложности. + +Если разрабатываемое вами приложение ориентировано на работу с данными и ваши сценарии в основном подразумевают CRUD операции (создание, чтение, обновление, удаление), то вам не нужен DDD. Вам всего лишь нужен интерфейс манипуляцией данными в вашей хранилище. -Если в вашем приложении реализует менее 30 сценариев использования (Use Cases), может вам проще использовать фраемворки Symfony или Laravel, для -управленией всей бизнес логикой. +Если в вашем приложении реализует менее 30 сценариев использования (Use Cases), может вам проще использовать фраймворки Symfony или Laravel, для управлениея всей бизнес логикой. -Однако, если ваше приложение имеет более 30 сценариев использования, ваша система подвержена движению в сторону Большого Комка Грязи - (Big Ball of Mud). Если вы точно знаете что ваша система будет достаточно сложной, то вам следует рассмореть возможность - использования DDD для борьбы с этой сложностью. - -Если вы знаете, что ваше приложение будет расти и, вероятно, часто изменяться, то DDD определенно -попожет вам в конетроле сложности и реализации рефакторинга вашей модели с течением времени. +Однако, если ваше приложение имеет более 30 сценариев использования, ваша система подвержена движению в сторону Большого Комка Грязи (Big Ball of Mud). Если вы точно знаете что ваша система будет достаточно сложной, то вам следует рассмотреть возможность использования DDD для борьбы с этой сложностью. -Если вам не понятен Домен (Domain), над которым вы работаете, потому что он новый и никто ранее не вкладывал средства -в это решение, это может означать, что он достаточно сложен для того чтобы с ходу начать применять DDD. -В этом случае вам стоит в первую очередь начать тесное взаимодействи с Экспертами Предметной Области Domain Experts для построения -правильной модели. +Если вы знаете, что ваше приложение будет расти и, вероятно, часто изменяться, то DDD определенно поможет вам в контроле сложности и реализации рефакторинга вашей модели с течением времени. + +Если вам не понятен Домен (Domain), над которым вы работаете, потому что он новый и никто ранее не вкладывал средства в это решение, это может означать, что он достаточно сложен для того чтобы с ходу начать применять DDD. +В этом случае вам стоит в первую очередь начать тесное взаимодействие с Экспертами Предметной Области Domain Experts для построения правильной модели. + +
## Некоторые нюансы -Применять DDD не просто. Необходимо время и усилия, чтобы построить Бизнес-Домен, создать терминалогию, провести иследования -и организовать сотрудничество с Экспертами Предметной Области используя Единый Язык, без профессиональных терминов программистов. -Вам потребуется участие Экспертов Предметной Области. Это в свою очередь потребует открытого, здорового и -непрерывного диалога, чтобы успешно перенести их терминалогию в модель програмного обеспечения. +Применять DDD не просто. Необходимо время и усилия, чтобы построить Бизнес-Домен, создать терминологию, провести исследования и организовать сотрудничество с Экспертами Предметной Области используя Единый Язык, без профессиональных терминов программистов. + +Вам потребуется участие Экспертов Предметной Области. Это в свою очередь потребует открытого, здорового и непрерывного диалога, чтобы успешно перенести их терминологию в модель программного обеспечения. + +Вдобавок ко всему, вам придется приложить усилия, чтобы избежать технических моментов реализации на начальном этапе, а сосредоточиться в первую очередь на поведении объектов и создании Единого Языка (Ubiquitous Language). -Вдобавок ко всему, вам придется приложить усилия, чтобы избежать технических моментов реализации на начальном этапе, а -сосредоточеться в первую очередь о поведени объектов и создани Единого Языка (Ubiquitous Language). +
## Стратегический обзор -Чтобы дать общий обзор стратегической стороны DDD, мы будем использовать подход из книги Джимми Нильссона «[Применение доменно-управляемого дизайна и шаблонов](http://www.williamspublishing.com/Books/978-5-8459-1296-1.html)» (Jimmy Nilsson "Applying Domain-Driven Design and Patterns"). Рассмотрим два разных пространства: пространство задач и пространство решений. - -В пространстве задач, DDD использует Домена (Domains) и Субдомены (Subdomains) для группировки и организации того, что -компания хочет решить (реализовать). В случае онлайн-агенства путешенствий (OTA), проблема заключается в том, чтобы иметь дело -с такими вещами, как авиабилеты и бронирование гостиниц. Такой Домен может бы огранизован в разные Субдомены, такие как: -ценообразование, инветаризация, управление пользователями и др. - -В пространстве решений, DDD предоставляет два патерна: Ограниченный Контекст (Bounded Context) и Карты Контекста (Context Map). -Целью является то, чтобы определить, как обеспечить реализацию для всех идентифицированных Поддоменов путем -определения их взаимодествия друг с другом и деталей этих самых взаимодествий. -Продолжая пример OTA каждый из Поддоменов будет решен с помощью реализации ограниченного контекста - например, -рассмотрим пользовательское веб-приложение, разработанное командой для Субдомена Управления Пользователями. -Карта контекста покажет, как каждый из Ограниченных контекстов связана с другими. Внутри Карты Контекста, мы можем видеть, какой тип -отношений имеют два Ограниченных Контекста (пример: клиент-поставщик (customer-supplier), партнеры (partners)). + +Чтобы дать общий обзор стратегической стороны DDD, мы будем использовать подход из книги Джимми Нильссона [Применение доменно-управляемого дизайна и шаблонов](http://www.williamspublishing.com/Books/978-5-8459-1296-1.html) (Jimmy Nilsson "Applying Domain-Driven Design and Patterns"). Рассмотрим два разных пространства: пространство задач и пространство решений. + +В пространстве задач, DDD использует Домены (Domains) и Субдомены (Subdomains) для группировки и организации того, что компания хочет решить (реализовать). В случае онлайн-агенства путешествий (OTA), проблема заключается в том, чтобы иметь дело с такими вещами, как авиабилеты и бронирование гостиниц. Такой Домен может бы огранизован в разные Субдомены, такие как: ценообразование, инвентаризация, управление пользователями и др. + +В пространстве решений, DDD предоставляет два паттерна: Ограниченный Контекст (Bounded Context) и Карты Контекста (Context Map). Целью является то, чтобы определить, как обеспечить реализацию для всех идентифицированных Поддоменов путем определения их взаимодействия друг с другом и деталей этих самых взаимодествий. +Продолжая пример OTA каждый из Поддоменов будет решен с помощью реализации ограниченного контекста. Например, рассмотрим пользовательское веб-приложение, разработанное командой для Субдомена Управления Пользователями. +Карта контекста покажет, как каждый из Ограниченных контекстов связан с другими. Внутри Карты Контекста, мы можем видеть, какой тип отношений имеют два Ограниченных Контекста (пример: клиент-поставщик (customer-supplier), партнеры (partners)). Идеальный подход состоит в том, чтобы каждый Субдомен реализовывался одним ограниченным контекстом, но это не всегда возможно. -С точки зрения реализации, следуя DDD, вы получите распределенные архитектуры. Как вы, возможно, уже знаете, распределенные архитектуры -более сложны, чем монолитные, так почему такой подход интересен, особенно у больших и сложных компаний? Это действительно стоит того? +С точки зрения реализации, следуя DDD, вы получите распределенные архитектуры. Как вы, возможно, уже знаете, распределенные архитектуры более сложны, чем монолитные, так почему такой подход интересен, особенно у больших и сложных компаний? Это действительно стоит того? В общем, да, это того стоит. -Подтверждено, что распределенные архитектуры увеличивают общую производительность компании, поскольку они определяют границы вашего продукта, -которые будут разрабатывать целевые команды разработчиков. +Подтверждено, что распределенные архитектуры увеличивают общую производительность компании, поскольку они определяют границы вашего продукта, которые будут разрабатывать целевые команды разработчиков. -Еслива ваш Домен (проблема которую вам нужно решить) - не сложный, то применение стратегической части DDD может добавить ненужные -накладные расходы и замедлить скорость разработки. +Если ваш Домен (проблема которую вам нужно решить) - не является сложным, то применение стратегической части DDD может добавить ненужные накладные расходы и замедлить скорость разработки. -Если вы хотите узнать больше о стратегической части DDD, вам следует взглянуть на первые три главы книги Вона Вернона -[Реализация методов предметно-ориентированного проектирования](http://www.williamspublishing.com/Books/978-5-8459-1881-9.html) -или книгу Эрика Эвинса "[Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем](http://www.williamspublishing.com/Books/978-5-8459-1597-9.html)". +Если вы хотите узнать больше о стратегической части DDD, вам следует взглянуть на первые три главы книги Вона Вернона +[Реализация методов предметно-ориентированного проектирования](http://www.williamspublishing.com/Books/978-5-8459-1881-9.html) +или книгу Эрика Эвинса [Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем](http://www.williamspublishing.com/Books/978-5-8459-1597-9.html). + +
## Связанные механизмы: Микросервисы и автономные системы. -Существуют другие механизмы, продвигающие архитектуры,которые следуют тем же принципам что и DDD. Микросервисы и Автономные системы являются хорошими примерами этого. -Джеймс Льюис и Мартин ФАулер дают определение Микросервисам в [Microservices Resource Guide](https://martinfowler.com/microservices/): +Существуют другие механизмы, продвигающие архитектуры, которые следуют тем же принципам что и DDD. Микросервисы и Автономные системы являются хорошими примерами этого. +Джеймс Льюис и Мартин Фаулер дают определение Микросервисам в *[Microservices Resource Guide]*(https://martinfowler.com/microservices/): + +
+ +> Архитектурный стиль микросервисов — это подход, при котором единое приложение строится как набор небольших сервисов, каждый из которых работает в собственном процессе и коммуницирует с остальными используя легковесные механизмы, как правило HTTP. Эти сервисы построены вокруг бизнес-потребностей и развертываются независимо с использованием полностью автоматизированной среды. Существует абсолютный минимум централизованного управления этими сервисами. Сами по себе эти сервисы могут быть написаны на разных языках и использовать разные технологии хранения данных. ->Архитектурный стиль микросервисов — это подход, при котором единое приложение строится как набор небольших сервисов, каждый из которых работает в собственном процессе и коммуницирует с остальными используя легковесные механизмы, как правило HTTP. Эти сервисы построены вокруг бизнес-потребностей и развертываются независимо с использованием полностью автоматизированной среды. Существует абсолютный минимум централизованного управления этими сервисами. Сами по себе эти сервисы могут быть написаны на разных языках и использовать разные технологии хранения данных. +
-Если вы хотите узнать больше о Микросервисах, начните с их руководства. Как это связанно с DDD? -Как объясняется в книге С.ма Ньюмана "[Создание Микросервисов](https://www.piter.com/product/sozdanie-mikroservisov)", -микросервисы являются реализацией Ограниченного контекста (Bounded Context) в DDD. +Если вы хотите узнать больше о Микросервисах, начните с их руководства. Как это связанно с DDD? +Как объясняется в книге Сэма Ньюмана [Создание Микросервисов](https://www.piter.com/product/sozdanie-mikroservisov), микросервисы являются реализацией Ограниченного контекста (Bounded Context) в DDD. -Помимо Микросервисов, другим связанным механизмом является Автономные Системы (Self-Contained Systems). Согласно веб-сайту -[Self-Contained Systems](http://scs-architecture.org/) +Помимо Микросервисов, другим связанным механизмом является Автономные Системы (Self-Contained Systems). Согласно веб-сайту [Self-Contained Systems](http://scs-architecture.org/) ->Подход «Автономная система» - это архитектура, которая фокусируется на разделении функциональности на множество независимых систем, что делает полную логическую систему совместной работой множества небольших программных систем. ->Это позволяет избежать проблемы крупных монолитов, которые постоянно растут и в конечном итоге становятся непригодными для эксплуатации. ->За последние несколько лет мы видели преимущества этого подхода во многих средних и крупных проектах. Идея состоит в том, чтобы разбить большую систему на несколько более мелких автономных систем или (SCS), которые следуют определенным правилам. +
+ +> Подход «Автономная система» - это архитектура, которая фокусируется на разделении функциональности на множество независимых систем, что делает полную логическую систему совместной работой множества небольших программных систем. +> Это позволяет избежать проблемы крупных монолитов, которые постоянно растут и в конечном итоге становятся непригодными для эксплуатации. +> За последние несколько лет мы видели преимущества этого подхода во многих средних и крупных проектах. Идея состоит в том, чтобы разбить большую систему на несколько более мелких автономных систем или (SCS), которые следуют определенным правилам. + +
На сайте также изложены семь характеристик SCS: - - Каждый SCS является автономным веб-приложением. - Для домена SCS все логические данные, логика обработки этих данных и весь код для визуализации веб-интерфейса содержатся в SCS. - SCS может выполнять свои основные сценарии использования самостоятельно, не полагаясь на другие доступные системы. - - Каждый SCS принадлежит одной команде. Это не обязательно означает, что только одна команда может изменить код, - но команда-владелец имеет решающее значение в отношении того, что входит в базу кода, например, путем объединения pull-requests. - - Связь с другими SCS или сторонними системами является асинхронной, где это возможно. - В частности, к другим SCS или внешним системам нельзя обращаться синхронно в пределах собственного цикла запроса/ответа SCS. - Это разъединяет системы, уменьшает последствия отказа и, таким образом, поддерживает автономию. - Цель состоит в том, чтобы развязать время выполнения задач: SCS должен работать, даже если другие SCS временно отключены. - Это может быть достигнуто, даже если связь на техническом уровне является синхронной, например, путем репликации данных или запросов буферизации. - - SCS может иметь дополнительный сервисный API. Поскольку у SCS есть собственный веб-интерфейс, он может взаимодействовать с пользователем, не обращаясь к службе UI. Однако API для мобильных клиентов или для других SCS может быть полезен. - - Каждая SCS должна включать данные и логику. Чтобы действительно реализовать какие-либо значимые функции, необходимы оба компонента. - - SCS должен сделать свои функции доступными для конечных пользователей с помощью собственного пользовательского интерфейса. - Поэтому у SCS не должно быть общего пользовательского интерфейса с другими SCS. SCS могут по-прежнему иметь ссылки друг на друга. - Однако асинхронная интеграция означает, что SCS все еще должен работать, если пользовательский интерфейс другого SCS недоступен. - Чтобы избежать тесной связи SCS, не следует делиться бизнес-кодом с другими SCS. - Может быть хорошо создать pull-request для SCS или использовать общие библиотеки, например: драйверы базы данных или oAuthclients. - - #### Упражнение - Обсудите плюсы и минусы распределенных архитектур с вашими коллегами по работе. Подумайте об использовании разных языков, - процессов развертывания, отвественности за инфраструктуру и так далее. - - ## Резюмируем - В этой главе вы узнали: - - - DDD - это не про технологию; на самом деле речь идет о предоставлении результатов в той области - в которой вы работаете, сосредоточившись на разработке модели. Каждый принимает участие в процессе проектирование Домена, и - разработчики и Эксперты Предметной Области объединяются для создания базы знаний, используя - один и тот же, Единый Язык (Ubiquitous Language). - - DDD предоставляет инструменты тактического и стратегического моделирования для разработки высококачественного ПО. - Стратегический дизайн нацелен на направление бизнеса, помогает определить внутрениие отношения и технически защищает каждую бизнес-службу, - создавая сильные границы. Тактическое проектирование предоставляет полезные строительные блоки для итеративного проектирования. - - DDD имеет смысл только в определенных задачах. Это не серебрянная пуля для любой проблемы в ПО, поэтому использовать подход или нет, во многом зависит от - сложности, с которой вы сталкнетесь. - - DDD - это долгосрочная инвестиция; это требует активных усилий. Эксперты Предметной Области должны тесно сотрудничать с разработчиками, - а разработчики должны думать с точки зрения бизнеса. В конечном итоге клиенты бизнеса - это те, кто должены быть довольны вашей работой. - - Реализация DDD требует усилий. Если бы это было легко, все писали бы качественный код. - Будьте готовы, потому что вы скоро узнаете, как писать код, который при прочтении отлично описывает бизнес вашей компании. - Наслаждайтесь этим приключением! \ No newline at end of file +- Каждый SCS является автономным веб-приложением. Для домена SCS все логические данные, логика обработки этих данных и весь код для визуализации веб-интерфейса содержатся в SCS. SCS может выполнять свои основные сценарии использования самостоятельно, не полагаясь на другие доступные системы. + +- Каждый SCS принадлежит одной команде. Это не обязательно означает, что только одна команда может изменить код, но команда-владелец имеет решающее значение в отношении того, что входит в базу кода, например, путем объединения pull-requests. + +- Связь с другими SCS или сторонними системами является асинхронной, где это возможно. В частности, к другим SCS или внешним системам нельзя обращаться синхронно в пределах собственного цикла запроса/ответа SCS. Это разъединяет системы, уменьшает последствия отказа и, таким образом, поддерживает автономию. Цель состоит в том, чтобы развязать время выполнения задач: SCS должен работать, даже если другие SCS временно отключены. Это может быть достигнуто, даже если связь на техническом уровне является синхронной, например, путем репликации данных или запросов буферизации. + +- SCS может иметь дополнительный сервисный API. Поскольку у SCS есть собственный веб-интерфейс, он может взаимодействовать с пользователем, не обращаясь к службе UI. Однако API для мобильных клиентов или для других SCS может быть полезен. + +- Каждая SCS должна включать данные и логику. Чтобы действительно реализовать какие-либо значимые функции, необходимы оба компонента. + +- SCS должен сделать свои функции доступными для конечных пользователей с помощью собственного пользовательского интерфейса. Поэтому у SCS не должно быть общего пользовательского интерфейса с другими SCS. SCS могут по-прежнему иметь ссылки друг на друга. Однако асинхронная интеграция означает, что SCS все еще должен работать, если пользовательский интерфейс другого SCS недоступен. + +Чтобы избежать тесной связи SCS, не следует делиться бизнес-кодом с другими SCS. Может быть хорошо создать pull-request для SCS или использовать общие библиотеки, например: драйверы базы данных или oAuthclients. + +#### Упражнение +Обсудите плюсы и минусы распределенных архитектур с вашими коллегами по работе. Подумайте об использовании разных языков, процессов развертывания, ответственности за инфраструктуру и так далее. + +
+ +## Резюмируем +В этой главе вы узнали: + +- DDD - это не про технологию. На самом деле речь идет о предоставлении результатов в той области в которой вы работаете, сосредоточившись на разработке модели. Каждый принимает участие в процессе проектирование Домена, и разработчики и Эксперты Предметной Области объединяются для создания базы знаний, используя один и тот же, Единый Язык (Ubiquitous Language). + +- DDD предоставляет инструменты тактического и стратегического моделирования для разработки высококачественного ПО. Стратегический дизайн нацелен на направление бизнеса, помогает определить внутренние отношения и технически защищает каждую бизнес-службу, создавая сильные границы. + Тактическое проектирование предоставляет полезные строительные блоки для итеративного проектирования. + +- DDD имеет смысл только в определенных задачах. Это не серебряная пуля для любой проблемы в ПО, поэтому использовать подход или нет, во многом зависит от + сложности, с которой вы столкнетесь. + +- DDD - это долгосрочная инвестиция. Это требует активных усилий. Эксперты Предметной Области должны тесно сотрудничать с разработчиками, а разработчики должны думать с точки зрения бизнеса. В конечном итоге клиенты бизнеса - это те, кто должны быть довольны вашей работой. + +Реализация DDD требует усилий. Если бы это было легко, все писали бы качественный код. Будьте готовы, потому что вы скоро узнаете, как писать код, который при прочтении отлично описывает бизнес вашей компании. +Наслаждайтесь этим приключением!