Затем, что все свои ошибки ты допустишь на ней и не придётся потом рефакторить возможное говно, которое можно заметить на uml.
Второе - uml не привязывается к языку - соответственно если что-то не устроит в проде на текущем стеке, его можно супер быстро переписать на что угодно.
В третьих - никакого кода, для понимания работы сервиса. Быстрое введение новичков в курс дела. Изучить синтаксис uml можно за пару вечеров, а вот стек проекта - нет.
Здесь скорее i/o интерфейсы, а уже как ты там это кодировать будешь и на чём - роли не играет.
Условно функция А принимает аргумент Б и возвращает данные типа В.
Хочется отдельный тип максимально короткого формата, то есть вынести string[] + указание что это json допустим в кастомный тип jsonArray и получить вот такое:
По моей задумке никакого кода не будет, пока не будут внесены изменения в uml.
А это на сугубо моей практике рабочий сервис с первого раза, по чёткой инструкции.
Если в инструкции нет ошибки разумеется.
В добавок если баг появился, его можно вычислить на уровне абстракции, а не дебажить сидеть.
Не совсем - если использовать стили, можно группировать сущности вообще любым способом и букву тоже менять можно, правда только одна помещается.
Что-то вроде типа в ts: type jsonStr = '["123"]'
class MyClass {
{field} +json_column: TEXT ({ "participantReaders": string[] })
}Потому-что это противоречит масштабированию команды, это ведь всё возможно будет поддерживаться уже не мной.
Если я буду делать как мне удобнее сейчас, что будет если это удобнее изменится через неделю? - переписывать, а мне лень :)
Мне человек сказал что ещё немного и я в 3d этот uml буду делать)
@startuml
abstract abstract
abstract class "abstract class"
annotation annotation
circle circle
() circle_short_form
class class
diamond diamond
<> diamond_short_form
entity entity
enum enum
interface interface
protocol protocol
struct struct
@endumlНе рисую, а пишу, рисовать пробовал, бред какой-то.