Привет!
Надоело мне мурыжить пост о построении диаграммы реального проекта, поэтому я волевым усилием его быстренько добил и с радостью представляю вашему вниманию:)
А дальше в серии будет два спиноффа - "Сцепленность" и "Объектный дизайн, как средство снижения сцепленности". Обе концепции у меня самого ещё не до конца разложены по полочкам, поэтому не берусь спрогнозировать сколько мне времени мне потребуется на эти посты.
После чего я смогу вернуться к третьему посту серии о применении диаграммы эффектов для объектной декомпозиции системы на модули. Но боюсь как бы это не осенью было.
#effects_diagram@ergonomic_code #case@ergonomic_code #project_geoservices@ergonomic_code #posts@ergonomic_code
Надоело мне мурыжить пост о построении диаграммы реального проекта, поэтому я волевым усилием его быстренько добил и с радостью представляю вашему вниманию:)
А дальше в серии будет два спиноффа - "Сцепленность" и "Объектный дизайн, как средство снижения сцепленности". Обе концепции у меня самого ещё не до конца разложены по полочкам, поэтому не берусь спрогнозировать сколько мне времени мне потребуется на эти посты.
После чего я смогу вернуться к третьему посту серии о применении диаграммы эффектов для объектной декомпозиции системы на модули. Но боюсь как бы это не осенью было.
#effects_diagram@ergonomic_code #case@ergonomic_code #project_geoservices@ergonomic_code #posts@ergonomic_code
Алексей Жидков
Диаграмма эффектов: пример построения - Алексей Жидков
Этот пост ялвяется второй частью из серии постов о диаграмме эффектов, в котором я рассмотрю пример построения диаграммы эффектов реального проекта
❤2
Привет!
Наконец-то деделал лэндинг и спеку для Диаграммы Эффектов.
Плюс на лэндинге выложил ещё один кейс диаграммы реального коммерческого проекта, значительно большего, чем True Story Project
#effects_diagram@ergonomic_code #ergo_approach@ergonomic_code #project_geoservices@ergonomic_code #case@ergonomic_code
Наконец-то деделал лэндинг и спеку для Диаграммы Эффектов.
Плюс на лэндинге выложил ещё один кейс диаграммы реального коммерческого проекта, значительно большего, чем True Story Project
#effects_diagram@ergonomic_code #ergo_approach@ergonomic_code #project_geoservices@ergonomic_code #case@ergonomic_code
Алексей Жидков
Диаграмма эффектов - Алексей Жидков
https://azhidkov.pro/
🔥6
image_2022-11-30_12-44-40.png
202.6 KB
Привет!
Я в целом собрал свою версию структуры модуля. Она всё так же похожа на структуру из Let's build components, not layers и базируется на интерфейсе и реализации. Но я решил отдельно вынести порты - штуки, которые публикуют АПИ модуля наружу и "конфиг" - спринговый конфиг, который позволяет создать экземпляр модуля в рантайме.
У меня получился такой список типовых (под)пакетов модуля:
- api
- dtos - классы DTO АПИ модуля
- events - классы событий модуля
- model - классы сущностей и объектов-значений из DDD, в случае если они "выставлены" в АПИ
- *Exception - файл с иерархией исключений модуля
- *Service - файл с интерфейсом модуля
- internal
- db - классы репозитория и сущностей модуля и, при наличии, DAO и строки
- submodule1 - подпакет с кодом реализации подмодуля
- Submodule2.kt - котлин-файл кодом реализации подмодуля
- *ServiceImpl - файл с классом реализации интерфейса модуля
- *Props - класс конфигурационных параметров модуля
- ports
- *Controller - Spring MVC контроллер и обработчик ошибок
- *Listener - Spring RabbitMQ слушателя
- *Config - Spring-конфигурация модуля
Я перепаковал так Проект Э, TSP Project и ещё один нетиповой проект - пока полёт нормальный. Дальше хочу ещё перепаковать Кэмп, Проект Л и ещё один коммерческий проект (у каждого из них есть уникальные особенности) и после этого пойти писать вторую версию поста "Структура эргономичной кодовой базы" (осторожно, материал этого поста частично устарел).
#ergo_approach@ergonomic_code #ergo_arch@ergonomic_code #project_e@ergonomic_code #project_camp@ergonomic_code #project_geoservices@ergonomic_code
Я в целом собрал свою версию структуры модуля. Она всё так же похожа на структуру из Let's build components, not layers и базируется на интерфейсе и реализации. Но я решил отдельно вынести порты - штуки, которые публикуют АПИ модуля наружу и "конфиг" - спринговый конфиг, который позволяет создать экземпляр модуля в рантайме.
У меня получился такой список типовых (под)пакетов модуля:
- api
- dtos - классы DTO АПИ модуля
- events - классы событий модуля
- model - классы сущностей и объектов-значений из DDD, в случае если они "выставлены" в АПИ
- *Exception - файл с иерархией исключений модуля
- *Service - файл с интерфейсом модуля
- internal
- db - классы репозитория и сущностей модуля и, при наличии, DAO и строки
- submodule1 - подпакет с кодом реализации подмодуля
- Submodule2.kt - котлин-файл кодом реализации подмодуля
- *ServiceImpl - файл с классом реализации интерфейса модуля
- *Props - класс конфигурационных параметров модуля
- ports
- *Controller - Spring MVC контроллер и обработчик ошибок
- *Listener - Spring RabbitMQ слушателя
- *Config - Spring-конфигурация модуля
Я перепаковал так Проект Э, TSP Project и ещё один нетиповой проект - пока полёт нормальный. Дальше хочу ещё перепаковать Кэмп, Проект Л и ещё один коммерческий проект (у каждого из них есть уникальные особенности) и после этого пойти писать вторую версию поста "Структура эргономичной кодовой базы" (осторожно, материал этого поста частично устарел).
#ergo_approach@ergonomic_code #ergo_arch@ergonomic_code #project_e@ergonomic_code #project_camp@ergonomic_code #project_geoservices@ergonomic_code
👍3🌚1