Project design in java

У вас должна появиться информация о версии программы:

id_rsa – закрытый ключ;
id_rsa.pub – открытый ключ;
known_hosts – при регистрации на других серверах сюда заносятся данные о подключениях.

Создаем репозиторий в своей учетной записи на GitHub

Создаем на GitHub новый репозиторий с таким же именем emc. Предварительно копируем содержимое файла id_rsa.pub из локального каталога .ssh. На GitHub в меню профиля пользователя находим пункт «SSH and GPG keys» и выбираем «New SSH key», задаем имя ключа, а в поле для ключа вставляем скопированное содержимое id_rsa.pub.

Пробуем забросить первые данные проекта в репозиторий на GitHub

Затем выбираем зависимости, которые нам понадобятся, в данном случае достаточно Spring Web.

Далее нажимаем Finish и ждем завершения процесса инициализации нового проекта.

Получаем, примерно, такой проект:

Проверяем тестовый проект на работоспособность

Для теста достаточно, чтобы приложение вывело в браузере текст «Hello World. «. В проекте создаем класс контроллер. В пакете com.barust.emc создаем новый класс HelloController .

Для компиляции и запуска, в окне Package Explorer открываем контекстное меню (правая кнопка мыши), находим пункт Run As и выбираем для запуска команду Spring Boot App.

Фиксируем локальный репозиторий проекта и выкладываем на GitHub

В предыдущих примерах по репозиторию Git мы работали с локальной папкой ~/emc, а теперь попробуем создать новый локальный репозиторий в проекте IDE STS4. В окне Package Explorer открываем контекстное меню, находим пункт Show in и выбираем для запуска команду Terminal (в Windows это Git Bash).

У вас должно появиться дополнительное терминальное окно.

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

Идем на GitHub и проверяем репозиторий:

Docker

Своим появлением Docker улучшил жизнь программистов, дав им такой мощный инструментарий как виртуальные контейнеры. Перед использованием Docker придется разобраться с основными понятиями.

Немного теории

Основу Docker составляют контейнеры, которые собираются из образов. Из образа вы можете создать несколько экземпляров контейнеров, которые будут отличаться портами TCP/UDP и независимостью. Также контейнеры могут взаимодействовать друг с другом. Ниже дается общая схема построения структуры Docker:

Клиентская часть – основной механизм/программа взаимодействия с Docker посредством терминала (мы будем пользоваться интерфейсом командной строки CLI).
Демон Docker – он же сервер Docker, управляет образами, контейнерами, сетями и томами.
Реестр Docker – это удаленный сервер для хранения готовых шаблонов образов, Docker Hub – один из вариантов реестра.
Docker Compose – если у вас многоконтейнерный проект, он позволяет управлять всеми контейнерами.

Надо учесть, что основу Docker составляют: образы, контейнеры и dockerfile. В dockerfile вы описываете содержимое контейнера. Обычно используются следующие инструкции:

FROM – родительский образ;
ENV – переменная окружения;
WORKDIR – рабочая директория для выполнения инструкций CMD и ENTRYPOINT;
COPY – копирование файлов и папок из вашей локальной директории в рабочую область образа;
LABEL – инструкция информационного характера;
RUN – запускает команды для установки пакетов и библиотек внутри контейнера;
CMD – указывает на команду для выполнения внутри контейнера, во время запуска;
ENTRYPOINT – также указывает на команду для выполнения внутри контейнера;
EXPOSE – определяет порты для внешнего доступа;
VOLUME – определяет маршрут для хранения данных и доступа к ним.

Dockerfile является как бы сердцем для Docker, указывая своими инструкциями, как построить образ.

Резюме

В этой статье мы подготовили основной необходимый инструментарий: Git/GitHub, SSH, Spring Boot и Docker. В следующей части цикла продолжим знакомство с Docker и на этом завершим подготовительный этап проекта. Думаю, это только начало – дальше будет еще интересней.

Источник

Project design in java

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

Пользовательские истории (User Experience, UX)

Основные определения

Дистанционное предоставление медицинских услуг, телемедицина.
Служба экстренной медицинской помощи.
Средства телекоммуникации – компьютер, мобильное устройство, Интернет.

Сценарий действий, как это будет происходить

Первичная регистрация пациента:

Регистрируется в системе (устанавливает приложение на свой компьютер или на мобильное устройство).
Заносит необходимые данные о себе.
Сервер регистрирует информацию о пациенте.

Рабочий процесс:

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

Читайте также: Что такое iterator php

Конечно, со стороны заказчика может быть предложен расширенный вариант UX. В нашем вымышленном проекте достаточно и этой информации.

🧩☕ Интересные задачи по Java для практики можно найти на нашем телеграм-канале «Библиотека задач по Java»

Строим архитектуру проекта

Определяем основную предметную область – это дистанционная экстренная медицинская помощь пациенту.

Определяем артефакты основной предметной области – у нас будут следующие артефакты:

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

Поддомены (ограниченные контексты)

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

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

В нашем случае, контексты, это:

вызов (recourse)

Эта область включает обращение пациента в службу экстренной помощи, а также следующие операции:

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

диагностика (diagnosis)

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

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

лечение (treatment)

Эта область включает в себя процесс лечения пациента, а также следующие операции:

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

отслеживание (tracking)

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

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

Давайте установим правила проектирования для нашего приложения.

в отношении ограниченных контекстов:

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

для связи микросервисов:

связи между агрегатами через идентификатор;
связь с внешними сервисами через миграцию данных;

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

Бизнес-область	Ограниченный контекст
вызов (recourse)	Вызов (recourse)
диагностика (diagnostics)	Диагноз (diagnose)
лечение (treatment)	Лечение (treatment)
отслеживание (tracking)	Отслеживание (tracking)

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

У нас будет два основных набора артефактов для модели предметной области.

— для модели основной предметной области:

— для операций модели предметной области:

команды (изменяют состояние в ограниченном контексте);
запросы (запрашивают состояние ограниченного контекста);
события (сообщают об изменении состояния ограниченного контекста).

Давайте, разберемся со всеми по порядку

Агрегаты (Aggregates) в ограниченном контексте

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

корневую сущность (Root Entity);
набор объектов-сущностей (Entity Objects);
набор объектов-значений (Value Objects).

Идентификаторы агрегатов

Каждый агрегат должен быть обозначен идентификатором агрегата (Aggregate Identifier) и реализуется при помощи бизнес-ключа (Business Key).

вызов (recourse) – Вызов (RecourseId);
диагностика (diagnosis) – Диагноз (DiagnoseId);
лечение (treatment) – Лечение (TreatmentId);
отслеживание (tracking) – Отслеживание (TrackingId).

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

Определяем сущности в наших агрегатах.

Объекты-значения (Value-Objects)

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

Это операции, которые требуют изменения состояния в ограниченном контексте.

Это операции, которые запрашивают состояние ограниченного контекста.

сообщают об изменении состояния ограниченного контекста.

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

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

Введем следующие определения. Ограниченный контекст:

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

Существует три типа сервисов модели предметной области для ограниченного контекста:

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

Резюме

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

А как же связать DDD с микросервисами? В следующей статье мы начнем третий этап – технический. На примере кодов попробуем применить предметно-ориентированное проектирование с микросервисами.

Источник