Распределенная архитектура приложения сейчас является наиболее актуальным выбором при проектировании корпоративных информационных систем. Такие архитектурные шаблоны как сервисно-ориентированная архитектура (SOA) и трехзвенная архитектура (3-tier architecture) являются de-facto стандартами в разработке корпоративных приложений.
Зачастую, главной проблемой в разработки является борьба со сложностью решаемой задачи, при этом для приложений уровня предприятия сложность с каждым годом стремительно увеличивается. Одним из наиболее эффективных средств борьбы с растущей сложностью является методология проектирования на основе модели предметной области (Domain Driven Design, DDD).
Каждый, кто пытался применить DDD в приложениях, имеющих распределенную архитектуру, будь то сервисы или клиент-сервер, знает с каким количеством трудностей приходится сталкиваться. В докладе будут рассмотрена целесообразность применения DDD в приложениях с сервисно-ориентированной архитектурой и в многозвенных приложениях, будут освещены трудности, возникающие при использовании DDD, и обозначены пути их преодоления. Будут даны ответы на вопросы:
- Стоит ли использовать DDD при разработке распределенных приложений?
- Как использовать DDD при использовании различных архитектурных стилей?
- Какую роль играют библиотеки, инструменты и фреймворки в разработке на основе модели предметной области?
- Какова эффективность использования DDD в agile-процессе разработки распределенных приложений?
Test Driven Development как инструмент уменьшения кадровых рисковngrebnev
Как мы все знаем, одним из ключевых факторов, определяющих успех проекта по разработке программного обеспечения, является команда реализующая проект. В случае если команда фиксируется на весь срок проекта, никто не болеет, все работают в одно и то же время, то проблем никаких не возникает. Но в реальности, команда меняется походу проекту, в проект приходят новые люди, ключевые участники проекта уходят в самый неожиданный момент, нередки случаи, когда на время надо срочно заменить выбывшего члена команды.
Ввод нового человека в проект — это всегда риски, риски, того, что у человека окажется недостаточно квалификации, риск внесения ошибок вследствие плохого знакомства с проектом. Неожиданное отсутствие члена команды проекта может, как минимум, привести к задержке сроков, а в случае, если другие не знакомы с его фронтом работ, то возможен и крах проекта. Незаменимость членов команды, введение нового человека в проект, завышенные ожидания от разработчиков - острейшие проблемы во многих проектах по разработке ПО, а особенно сильно эти проблемы проявляются на крупных проектах, где фиксировать состав команды и избежать всех неожиданностей физически невозможно.
Существенно снизить все выше перечисленные риски возможно при правильном использовании практики Test Driven Development (TDD). TDD — это техника разработки программного обеспечения, которая предполагает активное использование модульных тестов (unit-тестов), что делает их центральной частью дизайна системы. Разработка посредством тестирования при грамотном проектировании обеспечивает не только высокое качество ПО, но и стимулирует к созданию слабосвязанной архитектуры приложения. Более того, хорошо изолированными частями системы являются классы, т. е. фактически минимально возможный элемент системы. Слабая связность системы и хорошая изолированность ее частей, позволяют разработчикам быть уверенными, что их исправления или изменения будут локальными и не приведут к падению всей системы.
Хорошее покрытие тестами, а также архитектура приложения, к которой провоцирует использование TDD, обеспечивает не только качество программного обеспечения и хорошую самодокументируемость кода, но и позволяет быть у
Domain Driven Design - как, почему и зачем?ngrebnev
Одной из самых серьезных проблем в разработке программного обеспечения является борьба со сложностью решаемой задачи. Более того сложность задач решаемых разработчиками с каждым годом стремительно растет. Для решения этой проблемы хорошо себя зарекомендовал на практике набор подходов и методов, объединенных общим названием Domain Driven Design (DDD).
DDD позволяет существенно увеличить скорость разработки, снизить стоимость сопровождения и повысить качестве программного обеспечения. Но, несмотря на это, внедрение DDD на практике сталкивается с множеством трудностей и препятствий, что нередко приводит к полному отказу от применения данного похода в проекте.
Доклад посвящен описанию того как Domain Driven Design может быть использован в вашем проекте, зачем это вам нужно и почему это работает. Будут освещены преимущества и недостатки DDD, трудности с которыми приходится сталкиваться при его использовании и какой результат принесет его применение.
Эдуард Сергеев расскажет о том, как выработать единый подход к метрикам, что становится необходимо, когда в компании появляется хотя бы один по-настоящему крупный проект. Это позволит не только отслеживать его развитие в динамике, но и сравнивать эти показатели в дальнейшем с другими проектами.
Ссылка на видеозапись: https://youtu.be/rysvNokETnQ
Разработчик, аналитик, заказчик — как найти общий язык?ngrebnev
В проектах по разработке программного обеспечения участвуют множество различных специалистов, у которых разные роли, разные специализации, своя терминология, свой жаргон. И часто в проекте люди не понимают друг друга. Заказчики не понимают, почему те или иные доработки стоят так дорого. Аналитики вынуждены выступать переводчиками между пользователями и разработчиками. А разработчики работают сразу с двумя моделями системы — с моделью представленной аналитиками и моделью реализованной в коде. Это приводит к тому, что основные усилия расходуются не на разработку полезного функционала, а на попытки удержать обе модели в голове и сопоставить их друг с другом.
Методология Domain Driven Design (проектирование на основе предметной области — далее DDD) для решения этой проблемы предлагает в качестве единой опорной точки использовать модель предметной области. Такая модель хорошо понятна заказчикам, служит отличным инструментом для аналитиков. Но важной особенностью такой модели является то, что она может быть напрямую реализована в коде, а значит, пригодна для использования разработчиками.
При принятии решения всегда встают вопросы:
– Что такое Domain Driven Design?
– На каких проектах можно применить DDD? Является ли мой проект таким?
– Какова цена и какие риски?
– Какие типичные ошибки ждут на пути?
Test Driven Development как инструмент уменьшения кадровых рисковngrebnev
Как мы все знаем, одним из ключевых факторов, определяющих успех проекта по разработке программного обеспечения, является команда реализующая проект. В случае если команда фиксируется на весь срок проекта, никто не болеет, все работают в одно и то же время, то проблем никаких не возникает. Но в реальности, команда меняется походу проекту, в проект приходят новые люди, ключевые участники проекта уходят в самый неожиданный момент, нередки случаи, когда на время надо срочно заменить выбывшего члена команды.
Ввод нового человека в проект — это всегда риски, риски, того, что у человека окажется недостаточно квалификации, риск внесения ошибок вследствие плохого знакомства с проектом. Неожиданное отсутствие члена команды проекта может, как минимум, привести к задержке сроков, а в случае, если другие не знакомы с его фронтом работ, то возможен и крах проекта. Незаменимость членов команды, введение нового человека в проект, завышенные ожидания от разработчиков - острейшие проблемы во многих проектах по разработке ПО, а особенно сильно эти проблемы проявляются на крупных проектах, где фиксировать состав команды и избежать всех неожиданностей физически невозможно.
Существенно снизить все выше перечисленные риски возможно при правильном использовании практики Test Driven Development (TDD). TDD — это техника разработки программного обеспечения, которая предполагает активное использование модульных тестов (unit-тестов), что делает их центральной частью дизайна системы. Разработка посредством тестирования при грамотном проектировании обеспечивает не только высокое качество ПО, но и стимулирует к созданию слабосвязанной архитектуры приложения. Более того, хорошо изолированными частями системы являются классы, т. е. фактически минимально возможный элемент системы. Слабая связность системы и хорошая изолированность ее частей, позволяют разработчикам быть уверенными, что их исправления или изменения будут локальными и не приведут к падению всей системы.
Хорошее покрытие тестами, а также архитектура приложения, к которой провоцирует использование TDD, обеспечивает не только качество программного обеспечения и хорошую самодокументируемость кода, но и позволяет быть у
Domain Driven Design - как, почему и зачем?ngrebnev
Одной из самых серьезных проблем в разработке программного обеспечения является борьба со сложностью решаемой задачи. Более того сложность задач решаемых разработчиками с каждым годом стремительно растет. Для решения этой проблемы хорошо себя зарекомендовал на практике набор подходов и методов, объединенных общим названием Domain Driven Design (DDD).
DDD позволяет существенно увеличить скорость разработки, снизить стоимость сопровождения и повысить качестве программного обеспечения. Но, несмотря на это, внедрение DDD на практике сталкивается с множеством трудностей и препятствий, что нередко приводит к полному отказу от применения данного похода в проекте.
Доклад посвящен описанию того как Domain Driven Design может быть использован в вашем проекте, зачем это вам нужно и почему это работает. Будут освещены преимущества и недостатки DDD, трудности с которыми приходится сталкиваться при его использовании и какой результат принесет его применение.
Эдуард Сергеев расскажет о том, как выработать единый подход к метрикам, что становится необходимо, когда в компании появляется хотя бы один по-настоящему крупный проект. Это позволит не только отслеживать его развитие в динамике, но и сравнивать эти показатели в дальнейшем с другими проектами.
Ссылка на видеозапись: https://youtu.be/rysvNokETnQ
Разработчик, аналитик, заказчик — как найти общий язык?ngrebnev
В проектах по разработке программного обеспечения участвуют множество различных специалистов, у которых разные роли, разные специализации, своя терминология, свой жаргон. И часто в проекте люди не понимают друг друга. Заказчики не понимают, почему те или иные доработки стоят так дорого. Аналитики вынуждены выступать переводчиками между пользователями и разработчиками. А разработчики работают сразу с двумя моделями системы — с моделью представленной аналитиками и моделью реализованной в коде. Это приводит к тому, что основные усилия расходуются не на разработку полезного функционала, а на попытки удержать обе модели в голове и сопоставить их друг с другом.
Методология Domain Driven Design (проектирование на основе предметной области — далее DDD) для решения этой проблемы предлагает в качестве единой опорной точки использовать модель предметной области. Такая модель хорошо понятна заказчикам, служит отличным инструментом для аналитиков. Но важной особенностью такой модели является то, что она может быть напрямую реализована в коде, а значит, пригодна для использования разработчиками.
При принятии решения всегда встают вопросы:
– Что такое Domain Driven Design?
– На каких проектах можно применить DDD? Является ли мой проект таким?
– Какова цена и какие риски?
– Какие типичные ошибки ждут на пути?
Как использовать Rapid SQL для ускорения разработки SQL и другого кода для СУБДAndrew Sovtsov
Темы, рассмотренные на вебинаре:
знакомство с командной разработкой, работой с объектами БД
Как происходит отладка ..SQL
Зачем нужны Favorites и закладки
Как увидеть Explain-plans для запросов
Горячие клавиши, шаблоны, подстановка SQL
Как работает Query Builder
Строим простые и масштабируемые бекэндыDenis Ivanov
Презентация доклада на Microsoft DevCon 2016.
В чем кроется причина сложности создаваемых нами приложений? Ответ на этот философский вопрос пытаются получить каждый день специалисты IT-индустрии, основываясь на знаниях и опыте. Лучшие инженерные практики и паттерны проектирования призваны помочь в этом. В своем выступлении спикер поделится опытом создания бекэндов в сложных предметных областях и расскажет о проекте NuClear River — opensource-инструменте для построения Read Model-ей, который может значительно упростить решение некоторых бизнес-задач.
Записи докладов https://channel9.msdn.com/Events/DevCon/DevCon-2016
Поддержка NoSQL и платформ MongoDB, Hive и Teradata в продуктах EmbarcaderoAndrew Sovtsov
Технологии "Больших данных" все чаще находят свое место в информационных системах большинства компаний. Специалисты по работе с данными нуждаются в удобных решениях для работы с новыми технологиями в смешанных, многоплатформенных средах. Какие решения предлагает сегодня Embarcadero? Для архитекторов и специалистов по моделированию данных, администраторов БД и разработчиков серверных частей ИС. На русском языке.
Запись вебинара: http://youtu.be/sL5asNgFFG0
Миграция БД - практический_подход с инструментами EmbarcaderoAndrew Sovtsov
Слайды вебинара компании Embarcadero. Запись вебинара: https://www.youtube.com/watch?v=X9EjeB-aVHM
Одна из наиболее часто возникающих задач - выполнить перенос структур и необходимых данных из существующей БД в новую реализацию или на другую платформу СУБД. Предложены варианты комплексного решения подобных задач с использованием программных средств Embarcadero
More Related Content
Similar to Domain Driven Design в условиях разработки распределенных приложений
Как использовать Rapid SQL для ускорения разработки SQL и другого кода для СУБДAndrew Sovtsov
Темы, рассмотренные на вебинаре:
знакомство с командной разработкой, работой с объектами БД
Как происходит отладка ..SQL
Зачем нужны Favorites и закладки
Как увидеть Explain-plans для запросов
Горячие клавиши, шаблоны, подстановка SQL
Как работает Query Builder
Строим простые и масштабируемые бекэндыDenis Ivanov
Презентация доклада на Microsoft DevCon 2016.
В чем кроется причина сложности создаваемых нами приложений? Ответ на этот философский вопрос пытаются получить каждый день специалисты IT-индустрии, основываясь на знаниях и опыте. Лучшие инженерные практики и паттерны проектирования призваны помочь в этом. В своем выступлении спикер поделится опытом создания бекэндов в сложных предметных областях и расскажет о проекте NuClear River — opensource-инструменте для построения Read Model-ей, который может значительно упростить решение некоторых бизнес-задач.
Записи докладов https://channel9.msdn.com/Events/DevCon/DevCon-2016
Поддержка NoSQL и платформ MongoDB, Hive и Teradata в продуктах EmbarcaderoAndrew Sovtsov
Технологии "Больших данных" все чаще находят свое место в информационных системах большинства компаний. Специалисты по работе с данными нуждаются в удобных решениях для работы с новыми технологиями в смешанных, многоплатформенных средах. Какие решения предлагает сегодня Embarcadero? Для архитекторов и специалистов по моделированию данных, администраторов БД и разработчиков серверных частей ИС. На русском языке.
Запись вебинара: http://youtu.be/sL5asNgFFG0
Миграция БД - практический_подход с инструментами EmbarcaderoAndrew Sovtsov
Слайды вебинара компании Embarcadero. Запись вебинара: https://www.youtube.com/watch?v=X9EjeB-aVHM
Одна из наиболее часто возникающих задач - выполнить перенос структур и необходимых данных из существующей БД в новую реализацию или на другую платформу СУБД. Предложены варианты комплексного решения подобных задач с использованием программных средств Embarcadero
Similar to Domain Driven Design в условиях разработки распределенных приложений (20)
7. Domain Driven Design Проектирование по модели – проектирование архитектуры, при котором соблюдается максимально точное соответствие между некоторым подмножеством элементов программы и элементами модели (Эрик Эванс) 7
13. Domain Driven Design DDD – проекция языка предметной области на объектно ориентированный язык программирования 13
14. Почему DDD? Эффективный способ борьбы со сложностью Единый язык Низкая стоимость разработки и сопровождения 14
15. Почему DDD в Agile? Расстояние между заказчиком и разработчиком невелико Заказчик и разработчик разговаривают на одном языке Итеративная разработка – постепенное изменение модели 15
16. ORM (Object-relational mapping) ORM – технология программирования для конвертации данных между несовместимыми типами систем в объектно-ориентированные языки 16
66. 3-х звенная архитектура Тонкий клиент – см. клиент-сервер Толстый клиент: Мало логики – не использовать DDD на клиенте Средне логики – помещать инфраструктурный код в доменную модель Много логики – разработать свой слой преобразования данных 66
67. SOA и ESB Удаленного взаимодействия немного – поместить логику преобразования данных в доменную модель Иначе – разработать свой слой преобразования данных 67
72. Так что же делать? Оценить: Сложность доменной модели Необходимость сильно распределенной архитектуры Стоимость разработки собственных инструментов 72
73. Вопросы? Докладчик: Николай Гребнев e-mail: ngrebnev@gmail.com http://www.slideshare.net/ngrebnev/domain-driven-design-6988494 73