И ещё немного

Author: d-r-q

content/docs/models/ergo-arch.adoc

@@ -585,19 +585,25 @@ https://azhidkov.pro/posts/25/01/you-dont-need-ca-and-dip-probably/#_%D0%BF%D1%8
 
 На любом уровне можно добавить пакеты platform и infra.
 
+==== Пакеты platform
+
 Пакеты platform содержат:
-. определение верхнеуровневых функций (статических методов) и короткоживущих объектов, которые используются в нескольких элементах родительского пакета.
-  Например, в подпакете myapp.app.users.platform может быть класс ДТО, который используется в нескольких контроллерах пакета app.users.
-  Или в подпакете myapp.domain.users.platform может быть функция-утилита, которая используется в нескольких моделях/командах/запросах пакета myapp.domain.users.
-  Или в пакете myapp.platform.spring.jdbc могут быть функции-утилиты для класса JdbcClient, которые используются в разных пакетах ресурсов (в myapp.domain.*);
-. Определение классов компонентов для которых во время выполнения создаётся несколько экземпляров.
-  Например, это может быть компонент `FileStorage(name)`, который является деталью реализации нескольких ресурсов и, соответственно, каждый из которых используюет собственный экземпляр - `UsersRepo(usersDao, usersFileStorage)`, `ExercisesRepo(exercisesDao, exercisesFileStorage)`.
-
-Пакеты infra содержат:
-. определения управляемых DI-контейнером долгоживущие объекты, которые создают другие компоненты системы и или объекты их конфигурации, которые используются в нескольких элементах родительского пакета или инфраструктурой.
-  Например, в подпакете myapp.app.infra может быть определена Spring-конфигурация SecurityConf, задающая настройки авторизации всего приложения.
-  Или в подпакете myapp.domain.infra может быть определена Spring-конфигурация DataSourceConf, содержащая Spring-бин DataSource для всех ресурсов.
-  Или в подпакете myapp.infra может быть определена Spring-конфигурация CacheConf, создающая CacheManager, используемый в пакетах myapp.app и myapp.domain.
+
+* определение верхнеуровневых функций (статических методов) и короткоживущих объектов, которые используются в нескольких элементах родительского пакета.
+** Например, в пакете `myapp.app.users.platform` может быть класс ДТО, который используется в нескольких контроллерах пакета `app.users`.
+** Или в пакете `myapp.domain.users.platform` может быть функция-утилита, которая используется в нескольких моделях/командах/запросах пакета `myapp.domain`.users.
+** Или в пакете `myapp.platform.spring.jdbc` могут быть функции-утилиты для класса JdbcClient, которые используются в разных пакетах ресурсов (в `myapp.domain.*`);
+* Определение классов компонентов для которых во время выполнения создаётся несколько экземпляров.
+**  Например, это может быть компонент `FileStorage(name)`, который является деталью реализации нескольких ресурсов и, соответственно, каждый из которых используюет собственный экземпляр - `UsersRepo(usersDao, usersFileStorage)`, `ExercisesRepo(exercisesDao, exercisesFileStorage)`.
+
+==== Пакеты infra
+
+Пакеты infra содержат фабрики (как декларативные, так и императивные) инфраструктурных компонентов.
+
+Например, в пакете `myapp.app.infra` может быть определена Spring-конфигурация `SecurityConf`, задающая настройки авторизации всего приложения.
+Или в пакете `myapp.domain.infra` может быть определена Spring-конфигурация `DataSourceConf`, содержащая Spring-бин `DataSource` для всех ресурсов.
+Или в пакете `myapp.infra` может быть определена Spring-конфигурация `CacheConf`, создающая `CacheManager`, используемый в пакетах `myapp.app` и `myapp.domain``.
+
 
 В своём проекте вы можете выбрать другие стандартные имена или вообще выбирать подходящие имена в каждом конкретном случае.
 
@@ -606,29 +612,32 @@ https://azhidkov.pro/posts/25/01/you-dont-need-ca-and-dip-probably/#_%D0%BF%D1%8
 Всё вместе это выглядит так:
 
 
-* <org.my>
+* <org.my.app-name>
+
+** app - порты и операции системы
+*** app-module1 - модуль для раздела ТЗ/приложения-клиента/ресурса domain/ресурса REST API/фичи
+*** app-module2
+
+** domain - ядро системы - ресурсы, управляемые организацией-разработчиком
+*** resource1
+**** commands - ДТО команд на модификацию ресурса
+**** model - доменная/концептуальная модель данных ресурса
+**** persistence - персистентная модель и код работы со слоем персистанса
+**** queries - ДТО сложных запросов к состоянию ресурса
+**** views - ДТО представлений ресурса
+*** resource2
+
+** i9ns - интеграции - ресурсы, управляемые внешними организациями
+*** resource1
+*** resource2
+
+** infra - фабричный и/или адаптационный код компонентов, необходимых для работы всей системы
+
 ** platform - код, который потенциально можно переиспользовать в других приложениях в других предметных областях;
-*** lib1 
-*** lib2
-
-** <org.my.app-name>
-*** app - порты и операции системы
-**** app-module1 - модуль для раздела ТЗ/приложения-клиента/ресурса domain/ресурса REST API/фичи
-**** app-module2
-
-*** domain - ядро системы - ресурсы, управляемые организацией-разработчиком
-**** resource1
-***** commands
-***** model
-***** persistence
-***** queries
-***** views
-**** resource2
-
-*** i9ns - интеграции - ресурсы, управляемые внешними организациями
-**** resource1
-**** resource2
-
-*** infra - фабричный и/или адаптационный код компонентов, необходимых для работы всей системы
-
-*** platform - библиотечный код (как правило - расширения стандартной библиотеки и фреймворков), необходимый для работы системы
+*** errros - базоый класс доменных ошибок и классы стандарных доменных ошибок (ResourceNotFoundExceptoin, ResourceAlreadyExistsExeption и т.д.)
+*** files_storage - класс компоентов хранилища файлов
+*** kotlin - функции расширения для классов из стандартной библиотеки Kotlin
+*** postgresql - функции расширения для классов JDBC драйвера PostgreSQL
+*** spring
+**** data - функции расширения для классов из модуля Spring Data
+*** uuid - самописанная реализация UUIDv7