Domain Driven Design (DDD) — подход, предложенный Эриком Эвансом для эффективного проектирования и реализации приложений в сложных предметных областях. Основой его является создание модели будущей системы на едином языке (ubiquitous launguage), разрабатываемом для проекта и обеспечивающим надежные коммуникации между всеми участниками проекта. Модель, описанная на этом языке, согласуется с бизнес-заказчиком и верифицируется им, а затем отражается в реализацию системы с использованием типовых шаблонов, так что элементы и конструкции модели могут быть прослежены в коде. Таким образом обеспечивается соответствие поведения готовой системы потребностям заказчика, без чего сложные IT-проекты едва ли могут стать успешными.
В докладе будет дан общий обзор DDD на основе многолетнего успешного опыта его применения для разработки приложений — от построения модели с формированием единого языка до выработки шаблонов реализации типовых элементов модели.
DDD — эффективный способ работы в условиях системной сложностиCUSTIS
Выступление Максима Цепкова, нашего главного архитектора дирекции по развитию решений, на конференции CEE-SECR 2011 (31 октября – 3 ноября 2011 года, Москва).
Domain Driven Design - как, почему и зачем?ngrebnev
Одной из самых серьезных проблем в разработке программного обеспечения является борьба со сложностью решаемой задачи. Более того сложность задач решаемых разработчиками с каждым годом стремительно растет. Для решения этой проблемы хорошо себя зарекомендовал на практике набор подходов и методов, объединенных общим названием Domain Driven Design (DDD).
DDD позволяет существенно увеличить скорость разработки, снизить стоимость сопровождения и повысить качестве программного обеспечения. Но, несмотря на это, внедрение DDD на практике сталкивается с множеством трудностей и препятствий, что нередко приводит к полному отказу от применения данного похода в проекте.
Доклад посвящен описанию того как Domain Driven Design может быть использован в вашем проекте, зачем это вам нужно и почему это работает. Будут освещены преимущества и недостатки DDD, трудности с которыми приходится сталкиваться при его использовании и какой результат принесет его применение.
DDD — эффективный способ работы в условиях системной сложностиCUSTIS
Выступление Максима Цепкова, нашего главного архитектора дирекции по развитию решений, на конференции CEE-SECR 2011 (31 октября – 3 ноября 2011 года, Москва).
Domain Driven Design - как, почему и зачем?ngrebnev
Одной из самых серьезных проблем в разработке программного обеспечения является борьба со сложностью решаемой задачи. Более того сложность задач решаемых разработчиками с каждым годом стремительно растет. Для решения этой проблемы хорошо себя зарекомендовал на практике набор подходов и методов, объединенных общим названием Domain Driven Design (DDD).
DDD позволяет существенно увеличить скорость разработки, снизить стоимость сопровождения и повысить качестве программного обеспечения. Но, несмотря на это, внедрение DDD на практике сталкивается с множеством трудностей и препятствий, что нередко приводит к полному отказу от применения данного похода в проекте.
Доклад посвящен описанию того как Domain Driven Design может быть использован в вашем проекте, зачем это вам нужно и почему это работает. Будут освещены преимущества и недостатки DDD, трудности с которыми приходится сталкиваться при его использовании и какой результат принесет его применение.
Domain driven design (DDD) - отражение модели предметной области в код (Максим Цепков на Software People 2013). Подробнее http://mtsepkov.org/DDD_problem_and_solving
Проектирование Программных Систем. Лекция 01Dima Dzuba
Лекция рассказывает о базовых принципах построения программного обеспечения. Проводится сравнение гибких (Agile) и водопадных методологий разработки программного обеспечения.
DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...Alex V. Petrov
На примере одной специализированной, но значимой для большинства высокопроизводительных систем точки оптимизации исходного кода — работы с кэш-памятью — доклад «Достижима ли в C++ эффективность языка "среднего уровня"?», сделанный на DEV Labs 2013, показывает, какими несложными приемами и техниками можно достичь желаемого уровня эффективности объектно-ориентированного кода, и развеивает миф о языке C++ как языке «архитектурной астронавтики», предлагая аудитории ряд действенных рецептов повышения производительности исходного кода.
INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]Alex V. Petrov
Прошедший в «Академии информационных систем» (г. Москва) семинар «Как измерить архитектуру ПО?» ответил на вопрос о том, реально ли оценить архитектуру программной системы и сказать, насколько она полна, качественна, подвержена тем или иным недостаткам. В ходе семинара слушатели узнали, какие архитектурные метрики существуют, какие из них — признаны отраслью, в чем состоит их польза и как подходить к их применению в условиях производства.
Опыт госпроектов и взаимодействия с корпоративными структурамиПрофсоUX
Доклад предназначен для UX-специалистов, руководителей проектов и всех остальных.
В последнее время UX-специалисты и компании все чаще привлекаются к реализации проектов для корпораций и государственных заказчиков. На первый взгляд кажется, что при работе с ними попадаешь из мира сотрудничества в мир формальных взаимодействий. На самом деле построить с такими заказчиками настоящее сотрудничество вполне возможно. Более того, заказчик в нем заинтересован, просто не всегда представляет, как это сделать. В докладе я поделюсь практиками работы с крупными заказчиками из опыта компании CUSTIS.
HTP. Business Requirements Elicitation & Documentation [1.01, RUS]Alex V. Petrov
Приступая к реализации проектов разработки информационных систем, заказчик и исполнитель, как правило, в большей степени нацелены на подготовку технического задания. Однако, в действительности техническое задание — это финальный документ, в подготовке которого участвуют представители аналитического блока команды. Создание технического задания должно предваряться формированием ряда не менее важных документов, относящихся к более ранним этапам жизненного цикла системы. Одним из этих документов являются «Бизнес-требования» (англ. Business Requirements Document, BRD).
Ключевая миссия этого документа — исчерпывающее определение рамок, или объема, проекта. Какие объемы проекта существуют, как определяются и из чего складываются? Включать ли в BRD перечень заинтересованных сторон и предварительно идентифицированные риски проекта? Какую еще информацию следует включать в BRD, а какую — нет? Как провести границу между BRD и документом «Функциональные требования» (англ. Functional Requirements Document, FRD)? Как взаимодействовать с заказчиком для эффективного определения бизнес-требований? Ответы на эти и другие вопросы — в презентации с выступления в Парке высоких технологий (Минск, 03 декабря 2015 г.).встрече
Domain driven design (DDD) - отражение модели предметной области в код (Максим Цепков на Software People 2013). Подробнее http://mtsepkov.org/DDD_problem_and_solving
Проектирование Программных Систем. Лекция 01Dima Dzuba
Лекция рассказывает о базовых принципах построения программного обеспечения. Проводится сравнение гибких (Agile) и водопадных методологий разработки программного обеспечения.
DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...Alex V. Petrov
На примере одной специализированной, но значимой для большинства высокопроизводительных систем точки оптимизации исходного кода — работы с кэш-памятью — доклад «Достижима ли в C++ эффективность языка "среднего уровня"?», сделанный на DEV Labs 2013, показывает, какими несложными приемами и техниками можно достичь желаемого уровня эффективности объектно-ориентированного кода, и развеивает миф о языке C++ как языке «архитектурной астронавтики», предлагая аудитории ряд действенных рецептов повышения производительности исходного кода.
INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]Alex V. Petrov
Прошедший в «Академии информационных систем» (г. Москва) семинар «Как измерить архитектуру ПО?» ответил на вопрос о том, реально ли оценить архитектуру программной системы и сказать, насколько она полна, качественна, подвержена тем или иным недостаткам. В ходе семинара слушатели узнали, какие архитектурные метрики существуют, какие из них — признаны отраслью, в чем состоит их польза и как подходить к их применению в условиях производства.
Опыт госпроектов и взаимодействия с корпоративными структурамиПрофсоUX
Доклад предназначен для UX-специалистов, руководителей проектов и всех остальных.
В последнее время UX-специалисты и компании все чаще привлекаются к реализации проектов для корпораций и государственных заказчиков. На первый взгляд кажется, что при работе с ними попадаешь из мира сотрудничества в мир формальных взаимодействий. На самом деле построить с такими заказчиками настоящее сотрудничество вполне возможно. Более того, заказчик в нем заинтересован, просто не всегда представляет, как это сделать. В докладе я поделюсь практиками работы с крупными заказчиками из опыта компании CUSTIS.
HTP. Business Requirements Elicitation & Documentation [1.01, RUS]Alex V. Petrov
Приступая к реализации проектов разработки информационных систем, заказчик и исполнитель, как правило, в большей степени нацелены на подготовку технического задания. Однако, в действительности техническое задание — это финальный документ, в подготовке которого участвуют представители аналитического блока команды. Создание технического задания должно предваряться формированием ряда не менее важных документов, относящихся к более ранним этапам жизненного цикла системы. Одним из этих документов являются «Бизнес-требования» (англ. Business Requirements Document, BRD).
Ключевая миссия этого документа — исчерпывающее определение рамок, или объема, проекта. Какие объемы проекта существуют, как определяются и из чего складываются? Включать ли в BRD перечень заинтересованных сторон и предварительно идентифицированные риски проекта? Какую еще информацию следует включать в BRD, а какую — нет? Как провести границу между BRD и документом «Функциональные требования» (англ. Functional Requirements Document, FRD)? Как взаимодействовать с заказчиком для эффективного определения бизнес-требований? Ответы на эти и другие вопросы — в презентации с выступления в Парке высоких технологий (Минск, 03 декабря 2015 г.).встрече
Достоинства и ограничения проектных моделей водопада и гибких подходов: скрам, аджайл (scrum, agile).
Как на основе специфичных характеристик проекта подобрать модели планирования и управления ИТ проектом
Choose method for requirements Tsepkov Analyst Days-2017Maxim Tsepkov
Как выбрать для проекта практики проектирования и работы с требованиями (Максим Цепков на AnalystDays-2017). Страница доклада http://mtsepkov.org/Methods4req
Competency Model (HR API conference, Russian language) Irina Leshchuk
В докладе представлен опыт разработки, внедрения и использования модели компетенций для сотрудников компании. В нем говорится о том, как удалось подготовить решение, которое одновременно отвечает запросам со стороны бизнеса и используется для оценки и развития сотрудников в компании Grid Dynamics.
Кажется, что доклад будет интересен руководителям подразделений, менеджерам команд, HR специалистам и всем, кто интересуется вопросами оценки и развитием сотрудников внутри компании.
Целевой аудиторией, прежде всего, являются компании, в которых работает больше 100 инженеров и особенно актуально для тех, где есть распределенные команды в разных городах. Для компаний небольшого размера или стартапов содержание презентации будет интересно, скорее, с познавательной точки зрения, чем с практической.
Информационные системы управления бизнес-процессами (Business Process Management System, BPMS) позволяют моделировать и автоматизировать бизнес-процессы, отслеживать параметры их выполнения в режиме реального времени.
Подробнее http://www.croc.ru/solution/integration/integration/management
DIRECTUM: возможности системы электронного документооборотаDIRECTUM
Более подробная информация о модулях, бизнес-решениях и функциональных возможностях ECM-системы DIRECTUM на сайте http://www.directum.ru/system
Содержание:
- О системе
- Бизнес-решения
- Бизнес-консалтинг и внедрение
- Преимущества DIRECTUM
- Сообщество DIRECTUM
- Клиенты
- О разработчике
Softline — один из лидеров на рынке решений САПР/ГИС. Мы выполняем полный спектр работ по внедрению современных средств автоматизированного
проектирования ведущих зарубежных и отечественных производителей.
Основополагающий принцип автоматизированного проектирования — комплексный подход к решению задач. Размер наших проектов — от мелких доработок функционала сред проектирования до масштабного внедрения информационных систем поддержки процесса проектирования.
Б.Позин, Е.Горбунова -- развитие ядра Essence для стадии сопровожденияAnatoly Levenchuk
Доклад Бориса Позина и Eвгении Горбуновой "Предложение по развитию ядра OMG Essence для обеспечения процессов жизненного цикла программных систем" на 97 заседании INCOSE, 26 ноября 2014г.
Максим Цепков, Agile - то что на самом деле нужно гос.заказчикам!ScrumTrek
Многие доклады про использование гибких методологий разработки в проектах с государственным заказчиком рассказывают о том, как изолировать команду от заказчика для обеспечения Agile-процесса. Но нужно ли это на самом деле?
Ведь для заказчика, как правило, важно работающее программное обеспечение, а не документация на него, важно сотрудничество, а не контракты, важна готовность команды к изменениям — иными словами, те ценности, что декларирует Agile-манифест. Формальные требования воспринимаются заказчиком как дополнительная нагрузка на внутренние процессы, которые долго и сложно перестраивать. Поэтому секрет долгосрочного успешного сотрудничества — в грамотной адаптации деятельности компании-разработчика к условиям заказчика. За время доклада мы рассмотрим воплощение этого тезиса на конкретных примерах из опыта работы нашей компании с такими заказчиками, как Банк России, Газпромбанк и другими.
Similar to SECON'2014 - Максим Цепков - DDD: от требований до кода (20)
Я расскажу про то, как выполнять тяжелые задачи, требующие значительного количества серверных ресурсов и времени так, чтобы это оставалось незаметным для пользователя. Какую архитектуру выбрали мы, каким инструментом пользуемся для решения асинхронных задач в iFunny. Поделюсь опытом: какие трудности были встречены на пути перехода к асинхронным задачам, какие решения выбрали и как мы видим наше светлое будущее.
Доклад будет интересен всем, кто интересуется сложными распределенными системами.
Тезисы:
угадать тему и промахнуться одновременно;
планы разрушены, но могут возродится;
реакцию аудитории надо подвергать AB тестированию;
разные способы привлечения аудитории;
всем пох... ю до вас;
вся правда стартапа.
ЦА:
стартаперы;
интернет-маркетологи;
электронные СМИ;
журналисты.
Уровень аудитории — знающие, как делать проекты, пытавшиеся что-то продвигать в Интернете.
«В этом докладе я расскажу о том как мы подбираем команду и прокачиваем скиллы, приобщаем к использованию экстремального программирования и практик devops, справляемся с проблемами роста и распостраняем знания в команде, формируем систему ценностей и мотивируем, проводим code review и воспитываем лидеров».
Уровень аудитории: новички, практикующие, эксперты
Направления: Engineering & Quality, Agile Process, Team
Тезисы:
Работа системного администратора интересна и полна неожиданностей. До какого-то момента это приносит радость и удовлетворение. Но периодически специалист обнаруживает, что стоит в тупике, и не знает, куда идти дальше. В своем докладе я постараюсь построить карту таких «тупиков» и возможных путей выхода из них.
Целевая аудитория доклада, ее примерный уровень:
Доклад рассчитан как на тех, кто еще только выбирает свое направление в IT, так и на системных администраторов, внезапно обнаруживших «потолок» своего роста.
«Расскажу о том, как мы внедряли Agile с нуля и формировали команды на одном из ключевых проектов нашей компании (продуктовая команда — США, команда разработки, команда поддержки — Россия). С какими сложностями столкнулись, что для себя полезного почерпнули, как выглядят процессы сейчас и как планируем развиваться дальше в плане организации работ».
Аудитория: менеджеры проектов, Scrum-мастера
Любая система трекинга заявок, будь то JIRA, Redmine или YouTrack, умеет решать более-менее одинаковые задачи. В постоянно меняющемся мире лучше выживают те организмы, которые умеют быстрее приспосабливаться. Гибкость YouTrack придают два его уникальных свойства: во-первых, все правила, количество, названия, и типы полей в любом проекте полностью настраиваются, во-вторых, механизм workflow позволяет выполнять широкий спектр действий по таймеру или изменению issue. В докладе будет показано, как приспособить YouTrack к практически любым проектам, сводимым к работе с задачами или заявками, причем не только в разработке программного обеспечения, но и в ЖКХ. Будет затронута и тема интеграции с системами непрерывной интеграции (CI), почтой и мессенджерами.
Производительность имеет значение: производительность сайта напрямую влияет на успешность проекта и прибыль.
Что может быть измерено, может быть улучшено: основные показатели (метрики) производительности для веб-приложений: доступность и время отклика.
Почему нельзя доверять усредненным показателям? Процентили. Показатель удовлетворенности пользователей Apdex.
Тестируем производительность. Инструменты нагрузочного тестирования: ab, tsung, jmeter, blazemeter. Регрессионное тестирование производительности.
Следим за нагрузкой и производительностью на продакшен серверах. Инструменты: RRD, Graphite, NewRelic.
Из чего складывается производительность сайта: сервер + сеть + браузер.
Оптимизируем время загрузки страницы. Инструменты: YSlow, Google Page Speed, GTmetrix. Отдача статики с помощью Nginx, используем CDN, переносим сервера ближе к конечным пользователям.
Оптимизируем обработку запросов на сервере. Реверс-прокси. Php-fpm. Производительность СУБД. Кэширование. Стратегии обновления кэша. Асинхронность. Мониторинг фоновых процессов и очередей.
За последнее время очень сильное развитие получили мобильные приложения. Многие из нас используют свои любимые приложения каждый день. Push-уведомления являются очень важным инструментом для мобильных приложений. Рассылка push-уведомлений большому количеству пользователей является непростой задачей. В своем докладе расскажу о:
том, как устроены пуш-уведомления;
кейсах рассылки уведомлений в проектах mail.ru;
сложностях, которые возникают при рассылке push-уведомлений;
архитектуре сервиса рассылки;
асинхронных сервисах;
статистике и нагрузке на примере «живого» сервиса.
Доклад будет интересен всем, кто занимается разработкой сервисов для мобильных приложений.
«Расскажем о нашем опыте перехода к событийной модели при разработке одного из проектов заказчика. О том, какие подходы использовали, с какими проблемами столкнулись, как с ними боролись и что в итоге получили. А также о том, как бы сделали подобный проект, уже имея текущую экспертизу :)
Целевая аудитория: frontend-разработчики, познавшие боль при реализации сложных интерфейсных решений на базе коллбеков; использующие JS в качестве инструмента для разработки, а не только для подключения готовых скриптов».
Тезисы:
выбор Flash/Air при создании игры с 3D, сравнение с Unity3D;
обзор существующих во Flash 3D-библиотек;
трудности разработки 3D-игры на Flash;
особенности использования на мобильных платформах;
некоторые результаты.
Целевая аудитория:
все, кому интересна разработка игр, с любым уровнем вовлеченности в индустрию.
Для эффективной борьбы с большими данными одних технологий недостаточно. Необходим правильный настрой по отношению к ним, позволяющий видеть перспективы и особенности их использования. В данном рассказе предлагается точка зрения на совокупность проблем больших данных и их возможные пути разрешения. Рассказ построен на конкретных примерах из личной практики.
Целевая аудитория доклада, ее примерный уровень: аналитики, менеджеры ИТ, CTO.
Надежный обмен данными в гетерогенной среде, между разными платформами и технологиями является одним из ключевых моментов разработки сложных систем. Во время обмена данные преобразуются в некоторый промежуточный формат совместимый между платформами. Преобразование в подобный формат и из него — крайне рутинная и подверженная ошибкам работа.
Метаописание данных неким декларативным языком с последующей автогенерацией типизированных структур облегчает жизнь разработчику. Снимает с него необходимость задумываться о промежуточном формате, о правильном порядке полей, а типизированность гарантирует выявление ошибок еще на этапе компиляции кода.
В докладе будет рассмотрено несколько подобных решений, их плюсы и минусы. Также будет рассмотрен с практической стороны наш собственный формат метаданных, используемый нами на протяжении более 5 лет.
Целевая аудитория:
Ограничений нет, но в большей степени разработчики, имеющие уже определенный опыт разработки разнородных систем или приступающие к подобной задаче.
Необходимость использования средств управления конфигурацией в процессе эксплуатации сложных веб систем быстро становится очевидной, тем не менее, использование различных средств управления конфигурацией имеет свои нюансы и тонкости. Разные системы управления конфигурацией создавались с учетом различающихся требований их создателей, и они по-разному решают возложенные на них задачи. Доклад посвящен обобщению практического опыта применения четырех средств управления конфигурацией — Chef, Puppet, SaltStack и Ansible в гетерогенных окружениях разного размера, построенных на базе различных UNIX-подобных платформ, от FreeBSD и Linux до SmartOS.
Целевая аудитория доклада: веб-разработчики, инженеры отделов эксплуатации.
Ее примерный уровень: средний.
Типовые проекты, где в центре системы стоит реляционная БД, перестают удовлетворять современным требованиям рынка ПО. В норму входит использование очередей, поисковых движков, NoSQL решений, облачных технологий. Всё это требует перехода от «классической» архитектуры к дроблению системы на набор низкосвязанных компонентов, взаимодействующих друг с другом через сообщения или интерфейсы.
Мы рассмотрим примеры типовых подходов и инструментов, которые сейчас актуальны в мире разработки масштабируемых систем.
В рамках одного доклада мы расскажем, во первых, про наиболее популярные уязвимости веб-приложений. Также мы расскажем про такие классические вещи, как переполнение буфера (на стеке (stack) и на куче (heap), атаки на формат строки и не только. Многие про это слышали, но не многие знают, как этим может воспользоваться злоумышленник. Будет рассмотрена эксплуатация описанных уязвимостей без достаточной информации о приложении, принципы работы и написания шеллкода.
Будут функционировать два стенда, где все желающие могут попробовать свои силы и почувствовать себя настоящими хакерами.
Доклад будет интересен студентам и молодым разработчикам.
More from Конференция разработчиков программного обеспечения SECON'2014 (16)
2. SECON’14
Перенос подходов разработки на анализ
расширить?
Подумать про тестирование и внедрение
Идеи доработки
2/56
3. SECON’14
Есть разные способы ведения разработки
Выбор конкретного – зависит от проекта
В сложных проектах уместна работа с моделями
И DDD – наиболее эффективный способ для этого
О чем этот доклад?
DDD – ключ к построению сложных систем
и их развитию вслед за потребностями бизнеса
3/56
4. SECON’14
Требования
Проектирование
Реализация
Внедрение
Развитие системы
DDD – на полном жизненном цикле
4/56
http://en.wikipedia.org/wiki/V-Model_(software_development)
Не только модель
но и эффективные
коммуникации
5. SECON’14
Схема доклада
5/56
Часть 1
Проектирование модели
Detailed
Design
Implementation
Integration
and Test
MaintenanceConcept
Requirements
and
Architecture
System
Verification
Заключение – профит
Часть 2
От Модели до Кода
7. SECON’14
Теория
DDD – единый язык проекта и одна модель системы
• Модели были давно, но две: бизнес-область и система
• Единый язык проекта создает общее поле понятий
• И позволяет работать с одной, общей моделью
Практика
• Единый язык и построение Модели в конкретных примерах
• Практики проектирования – на этап бизнес-анализа
Проектирование в DDD
7/56
8. SECON’14
DDD – как оно начиналось
Концептуальная книга Эрика Эванса
• на английском – в 2003 г.
• на русском – только в 2010 г.
Практическая книга Джимми Нильссона
• на английском – в 2006 г.
• на русском – в 2007 г. (почти сразу!)
8/56
11. SECON’14
Построен на основе терминов предметной области
Его понимают ИТ-специалисты и эксперты бизнеса
На нем описана модель ИТ-системы и ее место в
бизнес-процессах
Единый язык (ubiquitous language)
Понятия единого языка:
Клиент, Накладная, платеж, Долг –
из предметной области
11/56
12. SECON’14
Модель системы не соответствует представлению
бизнеса о ее месте в модели предприятия.
Зачем нужен единый язык?
Модель предприятия
Представление
о месте
ИТ-системы
Модель
ИТ-системы
«Не то чтобы совсем не попал,
но только не попал в шарик…»
12/56
13. SECON’14
Единый язык позволяет совместить модель системы
с представлениями бизнеса о ее месте
Итерационное развитие модели
ИТ-система
Модель
ИТ-системы
Место ИТ
в бизнес-процессе
Управляющее воздействие
на модель
Итерация
13/56
14. SECON’14
Аналитик собирает требования и строит модель –
сначала предметной области, затем – системы
Артефакты модели описывают и систему и ее
использование в бизнес-процессах предприятия
Разработчик реализует модель
Артефакты модели можно проследить в коде
Единая модель
Модель предметной области
становится моделью системы
14/56
15. SECON’14
Верификация постановок бизнес-специалистами
Общее понимание требований на стороне бизнеса
Обсуждение модели бизнесом и IT, поиск баланса в
сложных решениях
Перенос моделей из других предметных областей
Бизнес представляет потенциальные возможности
системы и сложность различных доработок
На этапе эксплуатации – эффективное общение
бизнес-пользователей и IT без квалифицированных
переводчиков-аналитиков
Что мы достигаем?
15/56
17. SECON’14
Парадигма моделирования определяет
Элементы языка
Способ их соединения в сложные конструкции
Визуальный образ для представления
Способ отражения модели в код
ООП – парадигма моделирования
Объекты
с атрибутами
и методами
Диаграмма классов и
другие UML-диаграммы
Типы, соответствующие
бизнес-объектам
17/56
19. SECON’14
Не нужно
• Стараться изобразить все
классы на одной диаграмме
• Отображать
вспомогательные атрибуты
• Использовать технические
коды
• Использовать сложную
нотацию
Диаграммы должны
понимать заказчики, а
не только разработчики
Не нужно усложнять диаграмму
19/56
21. SECON’14
В процессе обработки документа (сделки, договора,
контракта) обеспечить проверку и одобрение
определенными сотрудниками или отделами
Задача
Задача касается
конкретного документа
21/56
23. SECON’14
Шаблоны обладают разной гибкостью и сложностью
Для выбора нужно понимать требуемый баланс
между гибкостью и сложностью решения
Традиционный подход
На этапе сбора требований аналитики
формулируют задачу для конкретного документа
Исходя из этого в системе проектируется решение
Выбранное решение отражает текущую ситуацию
В чем проблема?
Решение надо принимать с учетом
потенциального изменения бизнес-процессов
23/56
24. SECON’14
Проверка сделки казначейством и отделом рисков –
не получается выполнять параллельно
Юристы отозвали одобрение кредита, а служба
безопасности на него опиралась – связи между
визами не контролируются системой
Настройку виз для одобрения договоров с
недвижимостью передали в IT из-за сложности
Примеры
24/56
25. SECON’14
Представляем шаблоны, описанные применительно
к конкретному документу, показываем разницу
Бизнес-специалисты оценивают потенциальную
потребность в реализации бизнес-процессов
Решение принимается с учетом перспективы
Решение в рамках DDD
25/56
26. SECON’14
Для решения модель надо описать понятно бизнесу
• Можно описать обобщенные решения для документов,
«состояния» и «визы», и на них ссылаться
• Можно описывать каждый случай отдельно
Термины должны быть понятны Заказчику:
Например, «визированием» могут считать одобрение документа,
требующее только просмотра, а если требуется дополнительная
работа, то это называется «обработкой» или «проверкой»
Общий шаблон надо «перевести» на язык проекта
В чем Единый язык?
26/56
27. SECON’14
Мы используем известные шаблоны решений
Заказчик оценивает вариант решения не только с
точки зрения текущих потребностей, но и из
предположений о развитии бизнес-процессов
Проектируя изменения бизнес-процессов, заказчик
представляет потенциал гибкости системы и
принимает решения с учетом этого
Результат
27/56
29. SECON’14
Документ обрабатывается в несколько этапов.
На каждом этапе определенные сотрудники
могут совершать определенные действия.
Для передачи на следующий этап должны
выполняться определенные условия.
Обобщенный документооборот
29/56
30. SECON’14
Документу приписываем состояние.
Состояние определяет этап документооборота:
• какие действия можно совершать над документом;
• кто отвечает за обработку документа;
• кто имеет права на совершение тех или иных действий.
Возможные изменения состояний документа
образуют граф переходов.
Модель для документооборота
Вместо множества атрибутов используем
один, определяющий фазу жизненного цикла
30/56
31. SECON’14
Документ – объект предметной
области.
Действие над ним – вызов его метода.
Среди всех методов выделяем
переходы и связываем их
с состояниями.
Граф состояний – State machine
diagram.
Язык модели
UML
Язык ООП «с расширениями».
Названия состояний и переходов –
на языке бизнеса.
31/56
34. SECON’14
Стратегии
Политики
Выделение общих объектов
Абстракция через интерфейсы
Частные практики
Технические практики наполняются бизнес-
смыслом и служат для общения с Заказчиком
34/56
35. SECON’14
Перенос практик декомпозиции на бизнес-анализ
Понятие ограниченных контекстов
Различные варианты выделение общего
• Общее ядро
• Абстрактное ядро
• Подключаемые компоненты
• Крупноблочная структура
• Уровни разделения обязанностей
Изоляция и карта контекстов
Контексты
35/56
36. SECON’14
Часть 2. От модели до Кода
36/56
Часть 2
От Модели до Кода
Detailed
Design
Implementation
Integration
and Test
MaintenanceConcept
Requirements
and
Architecture
System
Verification
Заключение – профит
Часть 1
Проектирование модели
37. SECON’14
Язык, реализующий парадигму
Framework, часто с диаграммами,
например, MS Workflow Foundation
для реализации документооборота
DSL, лучше графический,
с компилятором или интерпретатором
Диаграммы и понятия единого языка
и шаблоны их отражения в реализацию
Как отражать модель в реализацию
37/56
Если нет готового –
приходится разрабатывать
38. SECON’14
На основе требований создаем объектную модель
• структура классов
• поведение объектов
• интерфейсы
Согласуем ее с заказчиком
Реализуем в коде на основе шаблонов
Domain model и Rich objects
Что получается?
Простое применение DDD
38/38
39. SECON’14
Соответствует парадигме современных языков
Понятна разработчикам и аналитикам
Имеет эффективные визуальное представление
Соответствует реальному миру и понимается
заказчиком – если проектировать бизнес-объекты
Достоинства объектной модели
39/56
40. SECON’14
ООП – общепринятый и (на простом уровне)
интуитивно понятный метод
Модель, сделанная в объектной парадигме, может
быть представлена заказчику и согласована с ним
Современные языки поддерживают ООП,
модель хорошо реализуется с использованием
шаблонов Domain model и Rich objects
Достоинства DDD с ООП
Этот способ работает, но ограниченно.
Простого ООП не хватает, а изучать сложный
заказчики не считают правильным
40/38
42. SECON’14
Документу приписываем состояние
Состояние определяет этап документооборота:
• какие действия можно совершать над документом
• кто отвечает за обработку документ
• кто имеет права на совершение тех или иных действий
Возможные изменения состояний документа
образуют граф переходов
Напомним решение
42/56
Шаблон State Entity
45. SECON’14
Из книги Нильссона
1. Императивно в коде конкретных методов
2. Императивно в едином методе
смены состояния
Варианты шаблона реализации
45/56
46. SECON’14
Из книги Нильссона
1. Императивно в коде конкретных методов
2. Императивно в едином методе смены состояния
3. Декларативно – через таблицу переходов и состояний
Варианты шаблона реализации
46/56
47. SECON’14
Из книги Нильссона
1. Императивно в коде конкретных методов
2. Императивно в едином методе смены состояния
3. Декларативно – через таблицу переходов и состояний
4. Через иерархию классов-состояний
Варианты шаблона реализации
47/56
48. SECON’14
Модель должна прозрачно отражаться в реализацию
Используем декларативное описание (3)
Или комбинацию (1) и (3):
• императивно изменяем состояние в методе перехода
• контролируем, что изменение соответствует декларативной
разметке
Таблица метаданных – декларативное описание –
однозначно соответствует диаграмме состояний
Что выбрать?
48/56
49. SECON’14
Иерархия классов-состояний – в объектной модели
• Полнее выразить реализацию в диаграмме классов
• Но поведение документа – за рамками, оно только в графе
переходов
• Поэтому для единого языка, понимаемого заказчиком – не
подходит
Почему не иерархия состояний?
49/56
50. SECON’14
Иерархия классов-состояний – в объектной модели
• Полнее выразить реализацию в диаграмме классов
• Но поведение документа – за рамками, оно только в графе
переходов
• Поэтому для единого языка, понимаемого заказчиком – не
подходит
Реализация через метаданные
• Таблица переходов отражает поведение документа в коде
• И однозначно соответствует диаграмме переходов
• Диаграмма переходов понимается заказчиком – единый язык
• При этом иерархия состояний становится излишней
• Однако, реализация требует выхода из объектной модели
Почему не иерархия состояний?
50/56
52. SECON’14
Отдельный проект
• Инициализация таблицы переходов для каждого документа
• Общая функция проверки перехода для всех методов
(вместе с логом)
• Таблица допустимых действий для каждого состояния (тоже
с логом)
Собственный объектный framework в Oracle
• Таблица переходов и прав в метаданных
• Вызов процедур-методов динамически с проверками
Реализация на разных платформах
52/56
53. SECON’14
Собственный фреймворк на C#
Разметка методов метаданными – состояния, права
Описание в метаданных графа состояний и условий
Обработка на посткомпиляции при создании
реализации
Реализация на разных платформах
53/56
[Method(AutoSave = true)]
[StateRestriction(RequestForShipmentState.New)]
[StateTransition(RequestForShipmentState.New, RequestForShipmentState.Created)]
[GrantInvocation(RmsRole.Manager)]
public virtual void PrepareForShipment()
{
State = RequestForShipmentState.Created;
...
55. SECON’14
Технические подробности и сложные формальные
методы становятся недопустимы
А без них модель не может служить проектом
для реализации, нужно дополнительное
проектирование
Проблемы при использовании
одной модели
Потому две модели
и использовали
Единственная модель на едином языке –
и преимущество DDD, и источник проблем
Необходимость понимания
модели заказчиком существенно
ограничивает моделирование
55/38
56. SECON’14
Бизнес-объект включает все аспекты деятельности
• Клиент – как субъект делового мира, партнер по сделкам,
взаимоотношения юридические и управленческие
• Заказ – полный жизненный цикл от начальных переговоров
до исполнения, включая юридическое и другое оформление
Бизнес-объекты тесно связаны между собой
При отражении в IT-объекты получается очень
похоже на антипаттерн Big Object
Сложно понимать, развивать, тестировать
Большие и сложные объекты
56/38
57. SECON’14
Принципы ООП побуждают к декомпозиции,
что увеличивает число объектов
Применение шаблонов (стратегии и др.)
Технические и инфраструктурные атрибуты
и классы
Ограничения на объекты со стороны фреймворков
и обходные пути для их преодоления
Сложная модель не понимается заказчиком,
простая – не отражает реализацию
Техническое усложнение модели
57/38
58. SECON’14
Подход разрабатывался для слоя бизнес-логики
Использование объектных языков побуждает
ограничиться объектными моделями
Хочется
Использовать модель при проектировании
интерфейсов
Расширять способы моделирования
Ограниченная область DDD-модели
58/38
60. SECON’14
Технологические рельсы – это способ перевода
модели на едином языке в код
Платформы, фреймворки и библиотеки
Способы их организации в единое приложение
Способы отражения модели приложения в код
Типовые задачи и design patterns для их реализации
Формулируются на всех уровнях – от архитектуры
до частных задач посылки сообщения
Что такое технологические рельсы
«Применяем Domain model и Rich Objects» –
частный случай технологических рельсов
60/38
64. SECON’14
Структура приложения в крупном, например:
Java с Hibernate и Spring
Создаем anemic-объекты с разметкой Hibernate
для каждого бизнес-класса, используем их так же,
как DTO для интерфейса
Бизнес-логику каждого класса реализуем в отдельном
статическом классе
Документооборот описываем через состояния
объекта, для реализации используем StateEntity
с декларативной таблицей состояний…
…
Архитектурные рельсы
Это способ реализации
модели в крупном
64/38
65. SECON’14
Способы реализации стандартных задач: печатных
форм, отправки сообщений, интеграции, например:
Все печатные формы реализуются с помощью
библиотеки X
Доступ к библиотеке – через сервис-локатор
Для бизнес-объекта с печатной формой
создаем класс PrintForm<TClass>, в котором каждой
форме соответствует отдельный метод…
На интерфейсе команды печати появляются
автоматически, исходя из созданных классов…
Инфраструктурные рельсы
65/38
66. SECON’14
Способ реализации конструкций, характерных
для предметной области проекта, например
документа с товарными строками:
Строки документов хранятся в отдельных таблицах,
однако в объектной модели доступ к ним –
исключительно через шапки документов
Для реализации типовой работы класс документа
наследуем от WareDoc<TDocHeader, TDocItem>,
что обеспечивает стандартный функционал…
Если документ не хранит цены и стоимость, а берет их
из справочников, реализуем стратегию PriceCalc
…
Рельсы предметной области
66/38
68. SECON’14
Задача: Для накладной надо печатать форму
ТОРГ-12
Задача – типовая, решение – единообразное
Требования к решению:
Отделить печать от бизнес-логики
Обеспечить независимое тестирование
Желательно обобщенное решение
Рельсы для печатной формы
Декомпозиция кода и независимое
тестирование – признаки хорошего стиля
68/38
69. SECON’14
Обобщенный сервис ПечатьТорг12
и метод НапечататьТорг12 у класса Накладная
Простое и очевидное решение
Увеличивается класс Накладная, в нем смешивается
разнородная бизнес-логика
Класс Накладная зависит от сервиса печати,
это сильно затрудняет тестирование
Печать форм: решение 1
ПечатьТорг12
…
ПечатьТорг12поНакладной()
…
Накладная
69/38
70. SECON’14
Обобщенный сервис ПечатьТорг12 и сервис
ПечатьТорг12поНакладной
Логика печати вынесена из бизнес-объектов
Для тестирования ПечатьТорг12поНакладной
необходима Накладная со всей инфраструктурой
Таких классов печати становится довольно много
Печать форм: решение 2
ПечатьТорг12
ПечатьТорг12поНакладной
Накладная
70/38
71. SECON’14
Обобщенный сервис ПечатьФормы и сервис
ПечатьТорг12поНакладной
Логика печати вынесена из бизнес-объектов
Печать и бизнес-логика тестируются независимо
Печать форм: решение 3
ПечатьФормыДанныеДляПечати
ПечатьТорг12Накладная
Решение применяем ко всем задачам
печати, тогда в модели достаточно перечислить
формы
71/38
73. SECON’14
По опыту разработки
корпоративных приложений
Плохо представляет цикл жизни объекта
Плохо подходит для отражения потоков ресурсов
Плохо подходит для систем связанных показателей
Если для области автоматизации эти аспекты важны,
можно применять другие парадигмы
Недостатки объектной модели
73/56
74. SECON’14
У класса-документа есть атрибут состояние,
описывающий текущее место в документообороте
В модели для документов создаем диаграмму
состояний, на ней же показываем роли
В классе для каждого перехода реализуем метод,
помечая его метаданными
В начале и в конце метода перехода вызываем
PreTransit и PostTransit, которые обеспечивают
логирование и контролируют состояние документа
Диаграммы состояний
74/38
75. SECON’14
Реализуем конструктор обобщенных интерфейсов
на основе метаданных бизнес-объектов – таблиц
с фильтрами для просмотра, диалогов для изменения
Обеспечиваем точки расширения для реализации
дополнительной логики
В постановках на 90% интерфейсов – списки полей
Реализация требуется только для особых случаев
Модель для интерфейсов
75/38
76. SECON’14
Выбрать или придумать парадигму моделирования
• Объекты обмениваются сообщениями
• Ресурс выделяется действующим лицам
Определить визуальный образ единого языка
• Диаграммы взаимодействия и синхронизации
• Образ разрезания пиццы
Разработать правила отражения модели в код –
иначе элементы модели не найти в реализации
Лучше, если отражение будет по шаблонам
Как сделать необъектную модель?
76/56
77. SECON’14
Присутствуют в большинстве enterprise-приложений
Плохо описываются в терминах объектов
Решение
Специальные диаграммы учета
Базовое учетное ядро – обобщенный учет
Шаблон реализации диаграмм учета на учетном ядре
Учет описывается в адекватных терминах
Диаграммы обеспечивают эффективное понимание
Подробнее о диаграммах состояний и реализации учета –
в докладе на ADD-2011 «Необъектные модели предметной области»
Задачи ведения учета
77/38
79. SECON’14
Технологические рельсы:
сочетают описание модели в понятных заказчику
терминах со сложными техническими решениями
помогают соблюдать ограничения, накладываемые
фреймворками, платформами и библиотеками
на организацию программного кода, поддерживают
их совместную работу и однородность решений в рамках
проекта
Все это обеспечивает эффективную разработку
и является залогом долгого и успешного развития
ИТ-системы, уже находящейся в эксплуатации
Что достигнуто?
79/38
80. SECON’14
В небольших проектах аналитик и архитектор –
один человек
В крупных проектах аналитик создает модель, а
архитектор проектирует техническую реализацию
В классическом процессе каждый из них работает
со своей моделью
В DDD – совместная работа над одной моделью
Конфликты – ответственность плохо разграничена
Аналитик и архитектор
80/38
81. SECON’14
Аналитик – создает модель и согласует ее
Архитектор – отвечает за технологические рельсы,
которые обеспечивают эффективную реализацию
Конструкции единого языка – способ синхронизации
модели с технологическими рельсами
Разграничение ответственности
Эффективность проектных решений
обеспечивается технологическими рельсами
Параллельная работа над проектом
Разработка «с рельсами»
81/38
82. SECON’14
Единый язык + Единая модель:
обеспечивают надежную основу для общения всех
участников проекта при принятии решений;
успешно заменяют мелкую россыпь требований;
позволяют эффективно развивать сложную систему.
Это требует дополнительных усилий:
формирование единого языка;
понимание разработчиками предметной области.
По опыту, результат окупает усилия.
Что же обеспечивает DDD?
82/56
Спасибо! Вопросы?
Максим Цепков http://www.facebook.com/mtsepkov