Разработка ПО (архитект. ис)

Эталонная модель интероперабельности –

Семантический диссонанс

•Семантика – изучает смысловое значение единиц языка

•Диссонанс – то, что не соответствует чему-либо, нарушает гармонию

•В случае интеграции – семантические противоречия в концептуальных моделях

Интеграция корпоративных приложений

•Комбинация процессов, программного обеспечения, стандартов и аппаратного обеспечения, позволяющая им работать как единому целому.

Задачи интеграции - Налаживание функциональных связей между разными приложениями, созданными на разных платформах и продуктах, на заказ или собственных, распределенных географически.

Что интегрируют между собой:

•Бизнес-процессы

•Приложения

•Данные

•Платформы

Задачи интеграции. Стили и подходы интеграции.

Задачи интеграции - Налаживание функциональных связей между разными приложениями, созданными на разных платформах и продуктах, на заказ или собственных, распределенных географически.

Что интегрируют между собой:

•Бизнес-процессы

•Приложения

•Данные

•Платформы

Типы интеграционных задач:

•Информационные порталы

•Репликация (обновление) данных

•Бизнес-функции совместного использования

•SOA

•Распределенные бизнес-процессы

•B2B (business to business) интеграция

Стили и подходы интеграции

Подходы интеграции

Передача файлов Плюсы:

•Простота

•Очень низкая связность Минусы:

•Низкая оперативность синхронизации

•Низкая скорость передачи файлов

•Значительная нагрузка на генерацию файлов

Общая база данных Плюсы:

•Отсутствие необходимости синхронизации

•Семантический диссонанс разрешается на этапе проектирования Минусы:

•Схема БД становится общей, что не всегда возможно

•БД может стать узким местом производительности

Удаленный вызов процедур Плюсы:

•Высокая скорость обмена

•Инкапсуляция

•Синхронное взаимодействие

•Легкость реализации в случае единых платформ

•Возможность поддержки распределенных транзакций Минусы:

•Сильная связность

•Синхронное взаимодействие

Обмен сообщениями Плюсы:

•Низкая связность

•Асинхронное взаимодействие

•Отличная масштабируемость Минусы:

•Сильная связность

•Асинхронное взаимодействие

•Сложно поддерживать транзакцию

Преимущества сообщений:

•Удаленное взаимодействие

•Платформенная интеграция

•Асинхронное взаимодействие

•Регулирование нагрузок

•Надежное взаимодействие

•Работа в режиме offline

•Реализация mediator

Интеграция с помощью очередей сообщений. Основные понятия.

Канал сообщений

•Соединяет приложения

•Именованные

•Один канал отвечает за передачу одного типа сообщений

•Бывают персистентными или не персистентными

•Один-к-одному или Один-ко-Многим

Сообщение

•Наименьшая единица данных

•Передается по каналу сообщений

•Заголовок + Тело

Каналы и фильтры

Фильтр соединяет два канала

Маршрутизатор сообщений Выбирает нужные каналы для отправки сообщения

Транслятор сообщения Преобразовывает сообщения в разные типы

•Структуру данных (убрать наследование)

•Типы данных (строку в число)

•Представление данных (XML в JSON)

•Транспортный

Конечная точка – подключает приложение к каналам

DDD. Модель предметной области.

Domain Driven Design:

•driven - ощутивший влияние или вызванный определенной вещью. Предоставление мощностей для обеспечения работы машины или для того, чтобы что-нибудь сделать. Управляемая, оказывающая влияние и воздействие

•domain - область интереса или область, которую можно контролировать. Четко определенная или идентифицируемая сфера деятельности или сфера знаний. Предметная область.

Domain Driven Design - Проектирование (и разработка), направляемое предметной областью.

Модель - это такая интерпретация реальности, при которой из явлений извлекаются существенные для решения задачи аспекты, а лишние детали игнорируются.

Предметная область - четко определенная сфера деятельности или сфера знаний, в которой пользователь использует программное обеспечение

Модель предметной области - минимально необходимая, строго организованная выборка из предметной области, необходимая для решения поставленных задач.

Роль модели:

•Модель и дизайн программы взаимно определяют друг - друга

•Модель лежит в основе языка, на котором говорят все, участвующие в разработки (программисты, тестировщики, аналитики, заказчики … )

•Модель – дистиллированное знание

Моделирование:

•Установить связь между моделью и реализацией

•Ввести в обиход язык, основанный на модели

•Разработать информоемкую модель

•Осуществить дистилляцию модели

•Экспериментировать и проводить мозговые штурмы

Классический подход к разработке:

Предметная область

рабочая группа

Подход к разработке (почти DDD)

исходный

код

эксперт

рабочая группа

Переработка знаний (настоящий DDD):

эксперт

рабочая группа

Единый язык:

•Единый для всех членов команды

•Ответственность за язык несет вся команда

•Основа модели предметной области

Появление единого языка:

Выражение единого языка:

•heart of software – главное, в исходном коде программе

•Неформальные UML-эскизы – как дополнение, показывающие ту или иную часть модели

Ключевое:

Единый язык и описанная на модель предметной области, в первую очередь выражены в виде исходных кодов приложения! При выражении модели надо правильно использовать предоставляемые языком программирования (и его парадигмой) возможности.

DDD. Структурные элементы. Моделирование объектов.

Изоляция модели - Представлена Onion architecture, у Эванса описана устаревшая многослойная модель DDD.

Модель

предметно й области

Хранилище

Внешние системы

Уровень

Операционный:

•Содержит вызовы методов модели, организуя их в сценарий использования системы пользователем

•Знает что и когда, но не знает как

Предметной области:

•Содержит бизнес-правила, бизнес-логику.

•Знает как, но может не знать когда и почему

Сущности

•Идентифицируемые понятия

•При моделирование важно задавать только те операции и атрибуты, которые существенны для понятия

•Все остальное выносится в другие объекты, ассоциированные с сущностью

Объекты – значения:

•Понятие полностью определяется своими значениями Следовательно, идентификатор не нужен

•Используется подход immutable object (неизменяемый объект)

Entity vs Value Objects (Сущность против Стоимость объектов)

•Очень сильно зависит от моделируемой предметной области

Службы:

Признаки хорошей службы:

•Выполняемая ею операция соответствует понятию модели, не являющемуся естественной частью объека-сущности или объекта-значения

•Интерфейс службы определен через другие элементы модели предметной области

•Операция не имеет собственного состояния

Службы для изоляции: помогают изолировать модели от других слоев приложения.

DDD. Структурные элементы. Управление жизненным циклом.

Жизненный цикл сущности не равен жизненному циклу инстанса класса (объекта). Сложности:

•Целостность объекта во время его существования

•Возможная сложность в управлении циклом существования

Агрегаты:

Обеспечивают точку входа в модель (включая ассоциации) Содержат:

•Корень – сущность, которая и является точкой входа

•Границу контекста – что именно будет загружено вместе с корнем

Контролирует целостность агрегатов с точки зрения модели предметной области. Обращение к любому объекту, внутреннему по отношению к агрегату, может выполнятся только через корневой объект.

Доступ к сущностям в агрегате:

Назначение агрегатов:

•Гарантированность целостности агрегата

•Уменьшение ассоциаций между сущностями

Фабрики

•Создают агрегаты

•Снимают обязанность инициализации объекта с него самого Назначение фабрики – создание агрегатов с учетом их логической целостности.

Правила хороших фабрик:

•Каждый метод создания един и не делим

•Работаем с интерфейсами, а не конкретными реализациями

Сравнение фабрик и конструкторов:

•Фабрика почти всегда предпочтительней

•конструктор нельзя заменить, фабрику можно

•Правило – нельзя в конструкторе создавать вызывать другие конструкторы

Репозиторий (хранилище)

•Глобальный объект доступа к объектам

•Инкапсулирует действия с хранилищем за интерфейс

•Предоставляют интерфейс доступа к спискам агрегатов

Преимущества репозиториев:

•Предоставляют простую модель доступа к корневым агрегатам

•Выражают в себе проектные решения по способам доступа к объектам

•Позволяют легко заменить себя mock’ами при тестировании

Все вместе

•Голубое – то что не имеет прямого отношения к модели

•Желтое – атрибуты и операции понятий модели

•Розовое – управление жизненным циклом объектов модели