|
Domain Driven Design в условиях разработки распределенных приложений (Николай Гребнев, AgileDays-2011) — различия между версиями
Материал из CustisWiki
|
|
| Строка 4: |
Строка 4: |
| | ;Докладчик: [http://2011.agiledays.ru/members/profile/763/ Николай Гребнев] | | ;Докладчик: [http://2011.agiledays.ru/members/profile/763/ Николай Гребнев] |
| | <blockquote> | | <blockquote> |
| − | Распределенная архитектура приложения сейчас является наиболее актуальным выбором при проектировании корпоративных информационных систем. Такие архитектурные шаблоны как сервисно-ориентированная архитектура (SOA) и трехзвенная архитектура (3-tier architecture) являются de-facto стандартами в разработке корпоративных приложений. | + | Распределенная архитектура приложения сейчас является наиболее актуальным выбором при проектировании корпоративных информационных систем. Такие архитектурные шаблоны как сервисно-ориентированная архитектура (<tt>SOA</tt>) и трехзвенная архитектура (''3-tier architecture'') являются ''de-facto'' стандартами в разработке корпоративных приложений. |
| | | | |
| − | Зачастую, главной проблемой в разработки является борьба со сложностью решаемой задачи, при этом для приложений уровня предприятия сложность с каждым годом стремительно увеличивается. Одним из наиболее эффективных средств борьбы с растущей сложностью является методология проектирования на основе модели предметной области (Domain Driven Design, DDD). | + | Зачастую, главной проблемой в разработки является борьба со сложностью решаемой задачи, при этом для приложений уровня предприятия сложность с каждым годом стремительно увеличивается. Одним из наиболее эффективных средств борьбы с растущей сложностью является методология проектирования на основе модели предметной области (''Domain Driven Design'', ''DDD''). |
| | | | |
| − | Каждый, кто пытался применить DDD в приложениях, имеющих распределенную архитектуру, будь то сервисы или клиент-сервер, знает с каким количеством трудностей приходится сталкиваться. В докладе будут рассмотрена целесообразность применения DDD в приложениях с сервисно-ориентированной архитектурой и в многозвенных приложениях, будут освещены трудности, возникающие при использовании DDD, и обозначены пути их преодоления. Будут даны ответы на вопросы: | + | Каждый, кто пытался применить ''DDD'' в приложениях, имеющих распределенную архитектуру, будь то сервисы или клиент-сервер, знает с каким количеством трудностей приходится сталкиваться. В докладе будут рассмотрена целесообразность применения ''DDD'' в приложениях с сервисно-ориентированной архитектурой и в многозвенных приложениях, будут освещены трудности, возникающие при использовании ''DDD'', и обозначены пути их преодоления. Будут даны ответы на вопросы: |
| | | | |
| − | * Стоит ли использовать DDD при разработке распределенных приложений?
| + | Стоит ли использовать ''DDD'' при разработке распределенных приложений? |
| − | * Как использовать DDD при использовании различных архитектурных стилей?
| + | |
| − | * Какую роль играют библиотеки, инструменты и фреймворки в разработке на основе модели предметной области?
| + | Как использовать ''DDD'' при использовании различных архитектурных стилей? |
| − | * Какова эффективность использования DDD в agile-процессе разработки распределенных приложений?
| + | |
| | + | Какую роль играют библиотеки, инструменты и фреймворки в разработке на основе модели предметной области? |
| | + | |
| | + | Какова эффективность использования ''DDD'' в agile-процессе разработки распределенных приложений? |
| | </blockquote> | | </blockquote> |
| | | | |
Версия 22:48, 11 апреля 2011
Аннотация
- Докладчик
- Николай Гребнев
Распределенная архитектура приложения сейчас является наиболее актуальным выбором при проектировании корпоративных информационных систем. Такие архитектурные шаблоны как сервисно-ориентированная архитектура (SOA) и трехзвенная архитектура (3-tier architecture) являются de-facto стандартами в разработке корпоративных приложений.
Зачастую, главной проблемой в разработки является борьба со сложностью решаемой задачи, при этом для приложений уровня предприятия сложность с каждым годом стремительно увеличивается. Одним из наиболее эффективных средств борьбы с растущей сложностью является методология проектирования на основе модели предметной области (Domain Driven Design, DDD).
Каждый, кто пытался применить DDD в приложениях, имеющих распределенную архитектуру, будь то сервисы или клиент-сервер, знает с каким количеством трудностей приходится сталкиваться. В докладе будут рассмотрена целесообразность применения DDD в приложениях с сервисно-ориентированной архитектурой и в многозвенных приложениях, будут освещены трудности, возникающие при использовании DDD, и обозначены пути их преодоления. Будут даны ответы на вопросы:
Стоит ли использовать DDD при разработке распределенных приложений?
Как использовать DDD при использовании различных архитектурных стилей?
Какую роль играют библиотеки, инструменты и фреймворки в разработке на основе модели предметной области?
Какова эффективность использования DDD в agile-процессе разработки распределенных приложений?
Видео
Примечания
Призыв к зрителям!
Мы призываем всех зрителей видеозаписей докладов давать хоть какой-нибудь, желательно конструктивный feedback.
Где? — неважно.
В блогах, в форумах, в комментах — пофиг, лишь бы можно было найти, например, поиском по блогам, по ключевому слову «AgileDays» (ну и/или по названию доклада).
Что-то побольше твиттер-вскрика, хотя бы пару абзацев.
Да, иногда краткая характеристика бывает достаточной («маркетинговый булшит», «унылый самопиар» — обычно в адрес «спонсорских докладов»), но это очень, очень редко, а так хочется прочитать что-то большее, чем «сижу на XXX, говорят о YYY».
Что писать? Что хорошо, что плохо («плохо» неудачное слово, скажем, «неправильно на ваш взгляд»), как вы поняли то, что рассказано, как это спроецировалось конкретно на вас — все это фантастически важно и полезно:
- Другим потенциальным зрителям (смотреть/не смотреть, «правильно ли я понял»).
- И докладчикам:
- «Правильно ли меня поняли»,
- «Что я делал правильно, а что улучшить»
- Даже критический отзыв лучше, чем никакого!
- Плюс — это мотивация, это награда за немалый труд многие готовятся долго, раскрывают свой опыт, старательно делают слайды, репетируют выступление — и ради чего? двадцать минут театра перед парой десятков зритетелей и все?
- Организаторам конференций (этой и других) — они внимательно следят за отзывами, и пытаются понять, кого имеет смысл звать («рубит фишку и жжет!»), а к кому отнестись скептически, и если брать, то, например, «прокачать в части выступлений» — мы, например, старались это делать, итеративно рецензировали слайды, рассылали подборку литературы о правильных слайдах и искусстве выступлений.
- Безотносительно лично докладчиков — важно понять, исчерпала себя тема или для народа еще остаются откровениями то, что для более пресыщенных инфопотоками людей (а организаторы обычно такие) уже выглядит как «аццкий боян». Ну и вообще — что еще интересно, и что было бы интересно услышать-увидеть-пообщаться на тему о…
- Ну и кстати, мне тоже важно — вообще имел ли смысл весь этот сыр-бор с сьемкой, видеомонтажем и обработкой и публикацией (это, вообще-то дорогая работа, расценки профессионалов в этой области весьма недетские, при том, что до этого уровня монтажа им, как правило очень далеко), или кроме участников конференции эти темы никому не интересны. Может есть какие-то косяки в видео? или предложения как сделать лучше? — связывайтесь со мной, возможно это можно будет исправить (или хотя бы вырезать). Это кстати относится и к докладчикам — если есть какие-то
позорные неудачные моменты, или что-то не нравится — это можно убрать.
|
 |
