Три точки опоры в архитектуре корпоративных систем Докладчик: Максим Цепков

Software People 2011 Корпоративные приложения Заказная разработка сложных систем –Поддержка уникальных бизнес-процессов заказчика –Частые изменения системы – вместе c изменениями бизнеса –Постановки необходимо согласовывать с бизнес-пользователями Большие долгоживущие системы –Начальная разработка – 5–20 человеко-лет за 0,5–2 года –Активное развитие весь срок эксплуатации – 5–10 лет (бывает дольше) –Существенно меняется коллектив разработчиков и пользователей Учетно-аналитические системы –Учет – одна из основных функций системы –Учетные показатели – основа бизнес-логики и принятия решений –Связь учета с документооборотом должна быть прозрачна Наш опыт 2/36

Software People 2011 Что нужно для проектирования? Понятное описание системы –З–Заказчик владеет языком описания и верифицирует постановки –Р–Разработчики тоже свободно общаются на языке описания Прозрачное и ясное описание –К–Компактно представляет сложные конструкции системы –С–Соответствует реализации (программному коду) –С–Связывается с тем, что видит пользователь в системе Проект системы развивается вместе с системой –Н–На языке описания можно формулировать запросы на изменение –М–Можно оценить трудоемкость реализации доработок Ошибки в постановках – самый большой риск Понятное и прозрачное описание его снижает 3/36

Software People 2011 Как мы проектируем? Мы строим модель на языке предметной области Сначала это – модель самой предметной области Но очень быстро превращается в модель системы Оставаясь на языке предметной области Модель является архитектурой системы Модель итеративно развивается вместе с системой Применяем диаграммы и другие методы компактного представления сложных систем, разработанные в IT Наш опыт 4/36

Software People 2011 Наш способ – в мировом тренде Domain Driven Design – mainstream в проектировании Архитектура на основе модели предметной области Единый язык общения заказчиков и разработчиков Итеративное проектирование и разработка 5/36

Software People 2011 Подробнее о DDD Концептуальная книга Эрика Эванса –на английском – в 2003 г. –на русском – только в 2010 г. Практическая книга Джимми Нильссона –на английском – в 2006 г. –на русском – в 2007 г. (почти сразу!) Для знакомства – можно смотреть материалы, ссылки, слайды и видеозапись тренинга Андрея Бибичева: 6/36

Software People 2011 Учетная машина – DDD для корпоративного приложения Мы не просто применяем DDD при проектировании У нас сложился шаблон модели – Учетная машина Мы применяем его для учетных корпоративных приложений предприятий и банков 7/36

Software People 2011 Шаблон учетной машины 8/36

Software People 2011 Обобщенное учетное приложение Пользователи создают документы По необходимости заполняют справочники Потом документы исполняют При этом меняются учетные данные Которые влияют на исполнение документов И отражаются в отчетах 9/36

Software People 2011 Состав учетного приложения СВЯЗЬ 10/36

Software People 2011 Что такое учетные показатели? Учетные показатели – отражение реальных потоков обобщенных ресурсов (товаров, денег, долгов и др.) Учетные показатели нужны и важны в большинстве управленческих систем, а не только в бухгалтерии Бухгалтерия же отражает реальные потоки весьма опосредованно 11/36

Software People 2011 СВЯЗЬ Представление Учетной машины Документы исправочники– диаграмма классов Документооборот – диаграмма состояний Учет – диаграмма учета 12/36

Software People 2011 Как представить учет? Учет – основное назначение учетной системы Представление учета оказалось за рамками UML И вообще эффективного представления Мы придумали Диаграммы учета Они дают целостную учетную модель системы Наш метод 13/36

Software People 2011 Диаграммы учета Показывают, как отражается движение ресурсов в учете 14/36

Software People 2011 Подробно о диаграммах учета К сожалению, подробного описания нет Есть выступления на конференциях ЛАФ-2010ЛАФ-2010 – «Диаграммы планов счетов – средство моделирования и проектирования учета» SECR-2010SECR-2010 – «Учет ценных бумаг – сделать сложное простым» Презентация и видео Презентация и статья 15/36

Software People 2011 Документы (и справочники) Используем объектно-ориентированный подход Классы соответствуют бизнес-объектам – заказчик видит знакомые названия Используем цветовые выделения Единый язык Представляем диаграммой классов 16/36

Software People 2011 Связь документов с учетом При обработке и проведении документов возникают хозяйственные операции, отражаемые в учете Документу приписываем состояние Оно определяет отражение документа в учете и другие аспекты документооборота: –текущий этап обработки документа –ответственность за документ –права на совершение действий Наш метод 17/36

Software People 2011 Диаграмма переходов документа Граф состояний документа изображается на State Machine Diagram (UML) –узлы – состояния –ребра – методы-переходы Состояния и переходы называем в терминах бизнеса Состояния заказа Единый язык 18/36

Software People 2011 Итак, единая модель системы Модель системы представляется в проекциях –диаграмма классов – структура объектов и их методы –диаграмма учета – учетная модель системы –диаграмма состояний документов – документооборот Все проекции связаны между собой через методы- переходы, которые есть на всех диаграммах Эта модель – результат обобщения нашего опыта разработки корпоративных приложений В большинстве случаев проекций модели достаточно В терминах предметной области Единый язык 19/36

Software People 2011 Развитие модели в ходе проекта 20/36

Software People 2011 От модели предметной области – к модели системы Начало проекта (1–2 месяца) –Интерактив с заказчиком, анализ предметной области –Диаграмма классов и диаграмма учета в крупном –План поэтапной реализации по фрагментам предметной области Итеративная разработка (6–18 месяцев) –Детальное проектирование фрагмента системы –Уточнение структур данных и учета, проработка документооборота –Реализация спроектированного фрагмента Внедрение и эксплуатация (5–10 лет) –Реализация бизнес-процессов в рамках модели системы –Запросы на развитие системы в терминах модели Модель предметной области По фрагментам 21/36

Software People 2011 Развитие объектной модели Сначала основные классы без деталей Подробности – по ходу разработки –Уточняем иерархию типов –Определяем атрибуты и методы –Проектируем вспомогательные классы –Уточняем структуру ассоциаций между классами Не все делаем на первом этапе 22/36

Software People 2011 Развитие учета Уточнения –определяем аналитики –определяем источники событий учета Изменения –добавляем новые участки учета –добавляем транзитные счета 23/36

Software People 2011 Проработка документооборота От простого, определяемого учетом – к сложной поддержке бизнес-процессов 24/36

Software People 2011 Сложная модель связанных документов Диаграмма классов Диаграмма состояний Диаграмма учета Документы могут появляться в ходе развития проекта 25/36

Software People 2011 Реализация Учетной машины 26/36

Software People 2011 Платформа реализации Большинство приложений мы делаем на C# и Oracle Объектная модель реализуется понятным образом – создаем классы, реализуем методы и т. д. Для модели документооборота и учета нужно типовое отображение в объектную реализацию Что значит «типовое»? Для реализации достаточно постановок с диаграммами переходов и учета, дополнительного проектирования не требуется 27/36

Software People 2011 Реализация документооборота Для прозрачной модели это должно совпадать: учетные события – суть хозяйственные операции ВЗГЛЯД БИЗНЕСА Есть журнал хозяйственных операций, возникающих при обработке и проведении документов РЕАЛИЗАЦИЯ источник учета – события (Event Sourcing, Фаулер), они возникают в методах документовEvent Sourcing Единый язык 28/36

Software People 2011 Документооборот – как мы делаем Для документов применяем design pattern State Entity –У документов есть атрибут – состояние –Изменение состояния – через вызов метода объекта –Метод изменения состояния называется также переходом документа –Учетные события возникают на переходах документов Используем реализацию на метаданных – у метода описываем начальное и конечное состояния Диаграмма состояний и описание семантики переходов достаточно для реализации разработчиком 29/36

Software People 2011 Реализация учета Есть Patterns for Accounting Мартина Фаулера – отражение учета в объектную реализациюPatterns for Accounting –учетные счета и проводки –источник проводок – события У нас – более развитая реализация –хранение аналитических признаков на счетах и проводках –ведение остатков и оборотов учетных счетов –ведение детальных и агрегированных показателей Есть собственный язык описания – GL-XML Наш метод 30/36

Software People 2011 Объектная реализация учета Стрелки диаграммы переходов Стрелки диаграммы учета Аналитики счета Текущие остатки вычисляются автоматически Показатели вычисляются автоматически Эти счета изображены на диаграмме учета 31/36

Software People 2011 Реализация учета – как мы делаем Диаграмма учета определяет –набор учетных счетов и их аналитику –проводки, выполняемые по конкретным переходам Еще надо определить набор хранимых показателей, необходимых для эффективной работы отчетов Задача разработчика –описать набор счетов, аналитику счетов и аналитику проводок –описать хранимые показатели –обеспечить создание проводок на учетных событиях – императивно или декларативно 32/36

Software People 2011 Заключение (что я хотел сказать) 33/36

Software People 2011 Архитектура по модели – эффективно Domain Driven Design – архитектура на основе модели На едином языке предметной области Итеративно и сохраняя целостность Domain Driven Design – не только объектные модели 34/36

Software People 2011 Да будут архитектурные шаблоны Шаблоны программирования – не только для отдельных фрагментов, но и для приложения в целом Учетная машина – шаблон корпоративного приложения Проектирование на основе Domain Driven Design Типовое отображение в реализацию 35/36

Software People 2011 Спасибо! Вопросы? Максим Цепков 36/36