C4

Еще одна нотация. Довольно популярная и уже давно известная всем штука, но в последнее время все чаще начинаю ее встречать.

Итак, C4 это нотация для описания архитектуры программного обеспечения. Он помогает разработчикам и другим членам команды/проекта понять, как устроена программа. Эта модель имеет четыре уровня:

C1. System Context diagram
C2. Container diagram
C3. Component diagram
C4. Code diagram

По крайней мере так принято считать)

На самом деле есть еще 3 дополнительных диаграммы:

System Landscape Diagram
Dynamic Diagram
Deployment Diagram

Ставь 🤩 если понял почему такая картинка на этой публикации ❤️

#словодня

Зацените какую крутую обложку сгенерил с помощью ИИ 🤩

По задумке это #кабачок Миша)))
В комментах еще один прикольный вариант)

🐇🐇🐇🐇🐇

😲 Не ожидал, что дойдем до 5 уровня.

Благодарочка! ❤️

Метрика

Метрика это числовой показатель, на основании которого можно дать оценку качества/устойчивости к нагрузки/лояльности клиента и тд.

Работает это так:
1️⃣ определяется событие, которое необходимо подсчитывать;
2️⃣ при каждой инициации этого события в бизнес процессе - происходит фиксация;
3️⃣ строятся графики, собирается статистика.

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

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

#словодня

Вот так выглядит сегодняшний завтрак.

Нет, я не с дубу рухнул, не мой завтрак, а Мишин))

В составе завтрака:
🔵Романо(ромейн)
🔵Листовой(самый обычный)
🔵Салат Саланова
🔵Кейл кудрявый
🔵Укроп
🔵Петрушка
🔵Фрилис
🔵Руккола
🔵Кинза

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

Пс2, еще, конечно, траву всякую кладем, но тут вообще страшно перечислять. Как и засушку)))

Пс3, ну и да, как вы догадались, половина холодильника стабильно забита Мишиной зеленью😂

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

#кабачок

Что интересного тут еще есть, поле inn имеет кастомный тип, который "базируется" на типе string, но имеет определенный паттерн, описанный с помощью регулярного выражения. Таким образом мы получили обязательное поле, которое будет валидно только в том случае, если его заполнить 12-ю или 10-ю цифрами.

Кстати, об обязательности, тут я устраивал викторины про minOccurs и maxOccurs. minOccurs отвечает за минимальное количество повторений элемента, а maxOccurs – за максимальное. По умолчанию значения этих атрибутов равно единице. А теперь на нашем примере, что это означает?
⏩Все поля без этих атрибутов являются обязательными;
⏩Все поля с minOccurs=0 являются необязательными;
⏩Поле contact является необязательным массивом.

Еще хочу обратить внимание на "индикаторы" sequence и all. Эти индикаторы отвечают за установку порядка. То есть при использовании sequence элементы четко закреплены за своими местами(имеют обязательную последовательность), соответственно их нельзя менять местами. При использовании индикатора all поля могут идти в любом порядке. Для наглядности в примере XML взгляните на элементы внутри user, они как объявлены в XSD, так и идут в примере. Далее взгляните на массив contactList, который используется с индикатором all, видно как поля type и value чередуются и это абсолютно корректно.

Помимо этих 2 индикаторов порядка еще есть choice, который тоже очень удобен и используется как оператор "исключающего ИЛИ". То есть в примере, если бы вместо all использовался choice, то в XML был бы либо элемент type, либо элемент value. choice очень удобно использовать, когда одна XSD используется для описания всех API микросервиса. Например:

<xs:choice>
  <xs:element name="GetClientDataByIdRequest" type="GetClientDataByIdRequestType" />
  <xs:element name="GetClientDataByIdResponse" type="GetClientDataByIdResponseType" />
  <xs:element name="SendNotificationRequest" type="SendNotificationRequestType" />
  <xs:element name="SendNotificationResponse" type="SendNotificationResponseType" />
  <xs:element name="CheckClientRequest" type="CheckClientRequestType" />
  <xs:element name="CheckClientResponse" type="CheckClientResponseType" />
</xs:choice>

Еще из интересного, в 2 местах схемы я использовал Enum'ы. Суть примерно та же, что и у элемента inn, поле также базируется на типе string, однако вместо паттерна, используется ограничение в виде возможных вариантов заполнения. Например, поле type элемента contact, может быть заполнено исключительно тремя значениями:
🟢EMAIL
🟢PHONE
🟢TELEGRAM

Конечно же, в XSD-схему можно добавлять описание для полей. Делается это так:

  <xs:annotation>
    <xs:documentation>Текст с описанием элемента</xs:documentation>
  </xs:annotation>

Также стоит упомянуть, что можно использовать атрибуты. Вот так они описываются по схеме(один из вариантов):

 <xs:element name="product">
    <xs:complexType>
        <xs:simpleContent>
            <xs:restriction base="xs:string">
                <xs:attribute name="coast" type="xs:boolean" use="required"/>
                <xs:attribute name="sale" type="xs:boolean"/>
                <xs:attribute name="size" type="xs:integer"/>
                <xs:attribute name="model" type="xs:string"/>
            </xs:restriction>
        </xs:simpleContent>
    </xs:complexType>
  </xs:element>

А вот так это будет выглядеть в XML-примере:

<product coast="12000" sale="false" size="24" model="Asus">Монитор</product>

Но я считаю, что использование атрибутов, хоть и круто расширяет возможности XML относительно формата JSON, зато по факту ухудшает читаемость(не всегда и везде, но ухудшает), а также заведомо запрещает формировать JSON на основе схемы.
PS, да-да не смотря на то, что XSD используется в первую очередь для описания структуры сообщения/запроса в формате XML, но на самом деле на его основе можно также формировать и JSON. Ты по сути указываешь программе структуру документа – XSD, а далее говоришь в какой формат эту структуру зарендерить – XML или JSON.

#быстростатья часть 2