Анализ предметной области это кратко

Обновлено: 04.07.2024

Цель работы: получить представление о системном анализе предметной области.

Теоретическая часть

Процесс проектирования БД представляет собой последовательность переходов от неформального словесного описания информационной структуры предметной области к формализованному описанию объектов предметной области в терминах некоторой модели.

В общем случае можно выделить следующие этапы проектирования:

Системный анализ и словесное описание информационных объектов предметной области.
Проектирование инфологической модели предметной области — частично формализованное описание объектов предметной области в терминах некоторой семантической модели, например, в терминах ER-модели.
Даталогичеcкое или логическое проектирование БД, то есть описание БД в терминах принятой даталогической модели данных.
Физическое проектирование БД, то есть выбор эффективного размещения БД на внешних носителях для обеспечения наиболее эффективной работы приложения.

Если учитывать, что между вторым и третьим этапами необходимо принять решение, с использованием какой стандартной СУБД будет реализовываться наш проект, то условно процесс проектирования БД можно представить последовательностью выполнения пяти соответствующих этапов. Рассмотрим более подробно этапы проектирования БД.

Рисунок 1 - Этапы проектирования БД

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

С точки зрения проектирования БД в рамках системного анализа, необходимо осуществить первый этап, то есть провести подробное словесное описание объектов предметной области и реальных связей, которые присутствуют между описываемыми объектами. Желательно, чтобы данное описание позволяло корректно определить все взаимосвязи между объектами предметной области.

В общем случае существуют два подхода к выбору состава и структуры предметной области:

Функциональный подход — он реализует принцип движения "от задач" и применяется тогда, когда заранее известны функции некоторой группы лиц и комплексов задач, для обслуживания информационных потребностей которых создается рассматриваемая БД. В этом случае мы можем четко выделить минимальный необходимый набор объектов предметной области, которые должны быть описаны.
Предметный подход — когда информационные потребности будущих пользователей БД жестко не фиксируются. Они могут быть многоаспектными и весьма динамичными. Мы не можем точно выделить минимальный набор объектов предметной области, которые необходимо описывать. В описание предметной области в этом случае включаются такие объекты и взаимосвязи, которые наиболее характерны и наиболее существенны для нее. БД, конструируемая при этом, называется предметной, то есть она может быть использована при решении множества разнообразных, заранее не определенных задач. Конструирование предметной БД в некотором смысле кажется гораздо более заманчивым, однако трудность всеобщего охвата предметной области с невозможностью конкретизации потребностей пользователей может привести к избыточно сложной схеме БД, которая для конкретных задач будет неэффективной.

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

Системный анализ должен заканчиваться подробным описанием информации об объектах предметной области, которая требуется для решения конкретных задач и которая должна храниться в БД, формулировкой конкретных задач, которые будут решаться с использованием данной БД с кратким описанием алгоритмов их решения, описанием выходных документов, которые должны генерироваться в системе, описанием входных документов, которые служат основанием для заполнения данными БД.

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

Пусть требуется разработать информационную систему для автоматизации учета получения и выдачи книг в библиотеке. Система должна предусматривать режимы ведения системного каталога, отражающего перечень областей знаний, по которым имеются книги в библиотеке. Внутри библиотеки области знаний в систематическом каталоге могут иметь уникальный внутренний номер и полное наименование. Каждая книга может содержать сведения из нескольких областей знаний. Каждая книга в библиотеке может присутствовать в нескольких экземплярах. Каждая книга, хранящаяся в библиотеке, характеризуется следующими параметрами:

уникальный шифр;
название;
фамилии авторов (могут отсутствовать);
место издания (город);
издательство;
год издания;
количество страниц;
стоимость книги;
количество экземпляров книги в библиотеке.

Книги могут иметь одинаковые названия, но они различаются по своему уникальному шифру (ISBN).

В библиотеке ведется картотека читателей.

На каждого читателя в картотеку заносятся следующие сведения:

фамилия, имя, отчество;
домашний адрес;
телефон (будем считать, что у нас два телефона — рабочий и домашний);
дата рождения.

Каждому читателю присваивается уникальный номер читательского билета.

Каждый читатель может одновременно держать на руках не более 5 книг. Читатель не должен одновременно держать более одного экземпляра книги одного названия.

Каждая книга в библиотеке может присутствовать в нескольких экземплярах. Каждый экземпляр имеет следующие характеристики:

уникальный инвентарный номер;
шифр книги, который совпадает с уникальным шифром из описания книг;
место размещения в библиотеке.

В случае выдачи экземпляра книги читателю в библиотеке хранится специальный вкладыш, в котором должны быть записаны следующие сведения:

номер билета читателя, который взял книгу;
дата выдачи книги;
дата возврата.

Предусмотреть следующие ограничения на информацию в системе:

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

При работе с системой библиотекарь должен иметь возможность решать следующие задачи:

Принимать новые книги и регистрировать их в библиотеке.
Относить книги к одной или к нескольким областям знаний.
Проводить каталогизацию книг, то есть назначение новых инвентарных номеров вновь принятым книгам, и, помещая их на полки библиотеки, запоминать место размещения каждого экземпляра.
Проводить дополнительную каталогизацию, если поступило несколько экземпляров книги, которая уже есть в библиотеке, при этом информация о книге в предметный каталог не вносится, а каждому новому экземпляру присваивается новый инвентарный номер и для него определяется место на полке библиотеки.
Проводить списание старых и не пользующихся спросом книг. Списывать можно только книги, ни один экземпляр которых не находится у читателей. Списание проводится по специальному акту списания, который утверждается администрацией библиотеки.
Вести учет выданных книг читателям, при этом предполагается два режима работы: выдача книг читателю и прием от него возвращаемых им книг обратно в библиотеку. При выдаче книг фиксируется, когда и какой экземпляр книги был выдан данному читателю и к какому сроку читатель должен вернуть этот экземпляр книги. При выдаче книг наличие свободного экземпляра и его конкретный номер могут определяться по заданному уникальному шифру книги или инвентарный номер может быть известен заранее. Не требуется вести "историю" чтения книг, то есть требуется отражать только текущее состояние библиотеки. При приеме книги, возвращаемой читателем, проверяется соответствие возвращаемого инвентарного номера книги выданному инвентарному номеру, и она ставится на свое старое место на полку библиотеки.
Проводить списание утерянных читателем книг по специальному акту списания или замены, подписанному администрацией библиотеки.
Проводить закрытие абонемента читателя, то есть уничтожение данных о нем, если читатель хочет выписаться из библиотеки и не является ее должником, то есть за ним не числится ни одной библиотечной книги.

Читатель должен иметь возможность решать следующие задачи:

Администрация библиотеки должна иметь возможность получать сведения о должниках - читателях библиотеки, которые не вернули вовремя взятые книги; сведения о книгах, которые не являются популярными, т. е. ни один экземпляр которых не находится на руках у читателей; сведения о стоимости конкретной книги, для того чтобы установить возможность возмещения стоимости утерянной книги или возможность замены ее другой книгой; сведения о наиболее популярных книгах, то есть таких, все экземпляры которых находятся на руках у читателей.

Этот совсем небольшой пример показывает, что перед началом разработки необходимо иметь точное представление о том, что же должно выполняться в системе, какие пользователи в ней будут работать, какие задачи будет решать каждый пользователь. И это правильно, ведь когда строят здание, тоже заранее предполагается: для каких целей оно предназначено, в каком климате оно будет стоять, на какой почве, и в зависимости от этого проектировщики могут предложить нам тот или иной проект. Но, к сожалению, очень часто по отношению к базам данных считается, что все можно определить потом, когда проект системы уже создан. Отсутствие четких целей создания БД может свести на нет все усилия разработчиков, и проект БД получится "плохим", неудобным, не соответствующим ни реально моделируемому объекту, ни задачам, которые должны решаться с использованием данной БД.

Варианты индивидуальных заданий для выполнения семантического анализа предметно области:

1. Салон видео проката.

2. Салон аудио проката.

11. Отдел кадров предприятия.

24. Ремонтная мастерская техники (моб. Телефонов, орг техники, комп. Техники и т.п.)

Кaчecтвeнныe мeтoды сбора информации включают сбор, aнaлиз и интepпpeтaцию дaнныx пyтeм нaблюдeния зa тeм, чтo люди делают и гoвopят.

1. Глyбиннoe интepвью (фокус-группа)

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

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

Оптимальный размер фокус-группы колеблется от 8 до 12 человек.

2. Индивидуальное интервью — интервью, в котором участвует только исполнитель и заказчик.

3. Пpoeкциoнные мeтoды . Моделирование cитyaции в нaдeждe нa тo, чтo будет выявлена инфopмaция, кoтopyю нeвoзмoжнo пoлyчить пpи пpoвeдeнии пpямoгo oпpoca.

4. Нaблюдeниe в иccлeдoвaнияx пpeдcтaвляeт coбoй мeтoд cбopa пepвичнoй инфopмaции oб изyчaeмoм oбъeктe пyтeм нaблюдeния зa выбpaнными гpyппaми людeй, дeйcтвиями и cитyaциями.

Мoжeт быть иcпoльзoвaнo кaк иcтoчник инфopмaции для пocтpoeния гипoтeз, cлyжить для пpoвepки дaнныx, пoлyчeнныx дpyгими мeтoдaми, c eгo пoмoщью мoжнo извлeчь дoпoлнитeльныe cвeдeния oб изyчaeмoм oбъeктe.

Нaблюдeниe являeтcя вecьмa тpyдoeмким мeтoдoм. Офopмлeниe итoгoв нaблюдeний зaнимaeт пopoй в двa paзa бoльшe вpeмeни, чeм caмo нaблюдeниe.

Пo xapaктepy oкpyжaющeй oбcтaнoвки нaблюдeниe мoжeт быть пoлeвым, чтo oзнaчaeт, чтo пpoцeccы пpoxoдят в ecтecтвeннoй oбcтaнoвкe (в мaгaзинe, y витpины мaгaзинa), или лaбopaтopным, т.e. пpoвoдящимcя в иcкyccтвeннo coздaннoй cитyaции. Рeзyльтaты нaблюдeний фикcиpyютcя c пoмoщью ayдиo- или видeoтexники, в блoкнoтax и т.п.

5. Имитационное моделирование — это метод исследования, при котором изучаемая система заменяется моделью с достаточной точностью описывающей реальную систему и с ней проводятся эксперименты с целью получения информации об этой системе.

Экспериментирование с моделью называют имитацией (имитация — это постижение сути явления, не прибегая к экспериментам на реальном объекте).

Имитационное моделирование — это частный случай математического моделирования

Имитационная модель — логико-математическое описание объекта, которое может быть использовано для экспериментирования на компьютере в целях проектирования, анализа и оценки функционирования объекта.

Что определяют требования к ИС? Для чего нужен анализ предметной области?

Анализом предметной области (или бизнес-моделированием, если речь идет о потребностях коммерческой организации) называют деятельность, направленную на:

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

• выявление свойств желаемых результатов

• определение набора задач, для их достижения

• определение набора сущностей, необходимых при решении этих задач

• определение области ответственности будущей информационной системы

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

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

В каких отношениях состоят понятия Анализ предметной области и Бизнес-моделирование?

Бизнес-моделирование - это анализ предметной области, связанной с коммерческой организацией.

Бизнес-моделирование наследует анализ предметной области.

Анализ предметной области – это первый шаг этапа системного анализа, с которого начинается разработка информационной системы.

Разработчики должны научиться:

· понимать язык, на котором говорят заказчики;

· выявить цели их деятельности;

· определить набор решаемых ими задач;

· определить набор сущностей, с которыми приходится иметь дело при решении этих задач.

В каких отношениях состоят понятия Анализ предметной области и Бизнес-моделирование?

Целью этапа анализа является преобразование общих, расплывчатых знаний об исходной предметной области (требований заказчика) в точные определения и спецификации для разработчиков, а также генерация функционального описания системы.

На этом этапе определяются и специфицируются:

• внешние и внутренние условия работы системы;

• функциональная структура системы;

• распределение функций между человеком и системой, интерфейсы;

• требования к техническим, информационным и программным компонентам системы;

• требования к качеству и безопасности;

• состав технической и пользовательской документации;

• условия внедрения и эксплуатации.

Анализ требований

Обследование предприятия

• исследования системы управления предприятием,

• обследования функциональной и информационной структур,

• определения существующих и возможных потребителей информации.

Определение требований:

• формулируются цель и задачи проекта

• происходит сбор и определение всех возможных требований,

• происходит осознании контекста системы.

• Процесс анализа заключается в разборе требований полученных на предыдущем этапе, их уточнение и систематизация.

Обследование предприятия

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

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

На этом материале аналитик строит функциональную модель "Как есть" (As Is).

2. Привлекаются заинтересованные представители заказчика, а при необходимости и независимые эксперты.

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

• определении путей совершенствования системы управления на основе выделенных критериев качества.

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

Анализом предметной области занимаются системные аналитики или бизнес-аналитики .

Они передают полученные ими знания другим членам проектной команды, сформулировав их на более понятном разработчикам языке.

Для передачи этих знаний обычно служит некоторый набор моделей, в виде графических схем и текстовых документов.

Объектом моделирования является сама система. При этом необходимо точно определить границы системы, чтобы избежать включения в модель посторонних объектов.

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

Виды моделей

Формальные модели, используемые на этапе анализа предметной области можно разделить на две группы:

1. · модели, зависящие от подхода к разработке (структурного или объектно-ориентированного);

2. · модели, не зависящие от подхода к разработке.

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

IEEE Standard Glossary of Software Engineering Terminology (1990) определяет требования как:

1. Условия или возможности, необходимые пользователю для решения проблем или достижения целей;
2. Условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам;
3. Документированное представление условий или возможностей для пунктов 1 и 2.

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

Уровни требований

Уровень1 . Бизнес-требования

Уровень2 . Требования пользователей

Уровень3 . Функциональные требования

+ нефункциональные требования к каждому уровню.

Системный и структурный анализ

Разработка систем – это систематический процесс, который включает в себя такие этапы, как планирование, анализ, проектирование, развертывание и обслуживание.

Системный анализ - процесс сбора и интерпретации фактов, выявления проблем и разложения системы на ее компоненты.

Системный анализ проводится с целью изучения системы или ее частей с целью определения ее целей. Это метод решения проблем, который улучшает систему и гарантирует, что все компоненты системы работают эффективно для достижения своей цели.

Анализ определяет, что должна делать система .

Аналитики используют различные инструменты для понимания и описания информационной системы. Одним из способов является использование структурного анализа.

Структурный анализ – это метод разработки, который позволяет аналитику логически понимать систему и ее действия.

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

Он имеет следующие атрибуты:

• графический, который указывает на представление приложения.

• разделяет процессы так, что дает четкую картину потока системы.

• логично, а не физически, т. е. Элементы системы не зависят от поставщика или оборудования.

• подход, который работает от обзоров высокого уровня до деталей более низкого уровня.

11. Анализ предметной области: цели и задачи. Модели предметной области. Формальные определения. Классификация моделей. Методология IDEF0, синтаксис IDEF0-моделей.

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

Деятельность, направленная на выявление реальных потребностей заказчика, а также на выяснения смысла высказанных требований, называется анализом предметной области (бизнес-моделированием, если речь идет о потребностях коммерческой организации). Анализ предметной области – это первый шаг этапа системного анализа, с которого начинается разработка программной системы. Разработчики должны научиться

· понимать язык, на котором говорят заказчики;
· выявить цели их деятельности;
· определить набор решаемых ими задач;
· определить набор сущностей, с которыми приходится иметь дело при решении этих задач.

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

Виды моделей

Формальные модели, используемые на этапе анализа предметной области можно разделить на две группы:

· модели, зависящие от подхода к разработке (структурного или объектно-ориентированного);
· модели, не зависящие от подхода к разработке.

Методологии IDEF

В рамках проекта ICAM планировалась разработка семейства методологий моделирования различных аспектов функционирования систем:

IDEF0 – методология создания функциональной модели системы (основана на методе SADT Росса);
IDEF1 – методология создания информационной модели системы (основана на реляционной теории Кодда и использовании ER-диаграмм Чена);
IDEF2 – методология создания динамической модели системы;
IDEF3 – методология создания модели потоков работ (обычно используется вместе с диаграммами потоков данных DFD Data flow diagram)

Синтаксис IDEF0-моделей

Основной формой представления IDEF0-модели является диаграмма. Каждая IDEF0-диаграмма содержит блоки (работы) и дуги (стрелки). Блоки изображают функции моделируемой системы. Дуги связывают блоки вместе и отображают взаимодействия и взаимосвязи между ними.
Функциональные блоки на диаграмме изображаются прямоугольниками, а дуги – стрелками.

Основные правила

Каждая сторона функционального блока должна иметь стандартное отношение блок/стрелки:

· входные стрелки должны связываться с левой стороной блока;
· управляющие стрелки должны связываться с верхней стороной блока;
· выходные стрелки должны связываться с правой стороной блока;
· стрелки механизма (кроме стрелок вызова) должны указывать вверх и подключаться к нижней стороне блока;
· стрелки вызова механизма должны указывать вниз, подключаться к нижней стороне блока, и помечаться ссылкой на вызываемый блок

В метках стрелок использоваться следующие термины:

функция,
вход,
управление,
выход,
механизм,
вызов.

Сегменты стрелок, за исключением стрелок вызова, должны помечаться существительным или оборотом существительного. Чтобы связать стрелку с меткой, следует использовать "тильду" (~)

Принцип декомпозиции

Функции моделируемой системы могут быть разбиты на составные части и представлены в виде более подробных диаграмм (принцип декомпозиции).
Диаграмма верхнего уровня называется контекстной и обеспечивает наиболее общее описание объекта моделирования.
За этой диаграммой следует серия дочерних диаграмм, дающих детальное представление об объекте.

Состав

IDEF0-модели состоят из трех типов документов:

· графических диаграмм(главный компонент IDEF0-модели, содержащий блоки, стрелки, соединения блоков и стрелок и ассоциированные с ними отношения)
· текста(используется для объяснений и уточнений характеристик, потоков, внутриблочных соединений и т.д.)
· глоссария (предназначен для определения аббревиатур, ключевых слов и фраз, используемых в качестве имен и меток на диаграммах)

Эти документы имеют перекрестные ссылки друг на друга. В методологии IDEF0 существует 6 типов отношений между блоками в пределах одной диаграммы:

В этой статье используется служба доставки помощью дронов в качестве выполняемого примера. Дополнительные сведения о сценарии и соответствующей эталонной реализации можно получить здесь.

Вступление

Предметно-ориентированное проектирование (DDD) предоставляет платформу, которая может помочь в разработке набора хорошо продуманных микрослужб. Этот алгоритм имеет два отдельных этапа: стратегический и тактический. На стратегическом этапе определяется масштабная структура системы. Этот этап помогает гарантировать, что архитектура ориентирована на бизнес-возможности. На тактическом этапе DDD предоставляется набор конструктивных шаблонов, которые можно использовать для создания модели предметной области. Эти шаблоны включают в себя сущности, статистические выражения и службы предметных областей. Эти тактические шаблоны помогают создавать микрослужбы, имеющие слабую взаимозависимость и хорошую слаженность.

В этой статье и далее мы рассмотрим следующие шаги, применяя их к приложению доставки помощью Дронов:

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

Затем определите ограниченные контексты предметной области. Каждый ограниченный контекст содержит модель предметной области, которая представляет определенную подобласть крупного приложения.

В рамках ограниченного контекста примените тактические шаблоны DDD, чтобы определить сущности, статистические выражения и службы предметных областей.

На основе результатов предыдущего шага идентифицируйте микрослужбы в своем приложении.

В этой статье рассматриваются первые три шага, которые в первую очередь связаны с DDD. В следующей статье мы обсудим микрослужбы. Важно помнить, что предметно-ориентированное проектирование — это итеративный текущий процесс. Ограничения службы не зафиксированы. По мере развития приложения можно разбить службу на несколько небольших служб.

Эта статья не предназначена для демонстрации полного и исчерпывающего анализа предметной области. Мы намеренно сохранили пример кратко, чтобы продемонстрировать основные моменты. Общие сведения о проблемно-ориентированном проектировании можно найти в одноименной книге Эрика Эванса (Eric Evans), в которой был впервые представлен этот термин. Другим хорошим справочником является книга Вона Вернона (Vaughn Vernon) Реализация методов предметно-ориентированного проектирования.

Сценарий: Доставка помощью Дронов

Этот сценарий довольной сложный, так как его этапы включают планирование загруженности беспилотных летательных аппаратов, отслеживание посылок, управление учетными записями пользователей, а также хранение и анализ исторических данных. Кроме того, компания Fabrikam хочет быстро выйти на рынок, а затем быстро повторить этот процесс, добавив новые функции и возможности. Приложение должно работать в масштабе облака с высоким целевым уровнем обслуживания. Компания также ожидает, что в разных частях системы требования к хранению данных и выполнению запросов будут очень отличаться. С учетом всех этих факторов Fabrikam выбрала архитектуру микрослужб для приложения доставки беспилотными летательными аппаратами.

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

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

Прежде чем написать код, необходимо иметь общее представление о создаваемой системе. DDD начинается с моделирования бизнес-домена и создания модели предметной области. Модель предметной области — это абстрактная модель предметной области бизнеса. Она извлекает и организует знания о предметной области, а также предоставляет общий язык для разработчиков и экспертов соответствующей сферы.

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

Создавая схему, можно начать определять дискретные подобласти. Какие функции тесно связаны? Какие функции являются основными для бизнеса, а какие предоставляют вспомогательные службы? Что такое схема зависимостей? На начальном этапе технологии и подробности реализации не важны. Все же следует отметить место, где приложение нужно будет интегрировать с внешними системами, такими как CRM, система обработки оплаты или выставления счетов.

Пример: приложение доставки помощью Дронов

После первоначального анализа предметной области команда Fabrikam создала приблизительный эскиз, представляющий предметную область "Доставка с помощью дронов".

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

Если приложение зависит от внешней системы, есть риск, что может произойти утечка схемы данных внешней системы или API в приложение, что может скомпрометировать архитектурный проект. Это особенно верно в отношении устаревших систем, которые могут не следовать современным рекомендациям и могут использовать сложные схемы данных или устаревшие API. В этом случае важно иметь четко определенную границу между внешними системами и приложением. Для этой цели рекомендуется использовать шаблон подавления рисунок или шаблон уровня защиты от повреждений .

Определение ограниченных контекстов

Модель предметной области включает представления реальных вещей — пользователей, дронов, грузов и т. д. Но это не значит, что каждая часть системы должна использовать одни и те же представления для одних и тех же вещей.

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

Если бы мы попытались создать единую модель для обеих этих подсистем, это было бы излишне сложным. С течением времени модель будет все сложнее видоизменять, так как любые изменения должны будут удовлетворять несколько команд, работающих над отдельными подсистемами. Поэтому зачастую лучше разрабатывать отдельные модели, которые представляют один и тот же объект реального мира (в данном случае дрон) в двух разных контекстах. Каждая модель содержит только те функции и атрибуты, которые имеют отношение к конкретному контексту.

Именно здесь приходится использовать концепцию с ограниченным контекстом DDD. Ограниченный контекст — это просто граница внутри предметной области, где применяется конкретная модель предметной области. Рассматривая предыдущую схему, можно группировать функции в зависимости от того, будут ли различные функции использовать одну модель предметной области.

Ограниченные контексты не обязательно изолировать друг от друга. На этой схеме сплошные линии, соединяющие ограниченные контексты, представляют места, где взаимодействуют два ограниченных контекста. Например, область "Доставка" зависит от области "Учетные записи пользователей" для получения информации о клиентах и от области "Управление дронами" для планирования полетов отдельных дронов.

В книге Проблемно-ориентированное проектирование Эрик Эванс описывает шаблоны по поддержке целостности модели предметной области при взаимодействии с другим ограниченным контекстом. Одним из основных принципов микрослужб является то, что службы обмениваются данными через четко определенные API. Этот подход соответствует двум шаблонам, которые Эванс называет открытой службой размещения и опубликованным языком. Идея открытой службы размещения заключается в том, что подсистема определяет формальный протокол (API), через который другие подсистемы могут взаимодействовать с ней. Опубликованный язык расширяет эту идею, публикуя API в форме, которую другие команды могут использовать для написания клиентов. В статье проектирование интерфейсов API для микрослужбмы поговорим об использовании спецификации OpenAPI (прежнее название — Swagger) для определения независимых от языка описаний интерфейсов для интерфейсов API, выраженных в формате JSON или YAML.

В оставшейся части этого руководства мы сконцентрируемся на ограниченном контексте доставки.

Дальнейшие действия

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

Читайте также: