Привет

Сегодня у нас рубрика "Мои факапы".

Есть у меня один проект, где флоу создания одной из сущностей такой:
1) непривилегированный пользователь создаёт сущность
2) привилегированный пользователь её одобряет или отклоняет

ну и плюс привилегированный пользователь может её редактировать в любой момент.

я уже подробностей дизайна не помню, но с одной стороны у меня вроде были какие-то трудности с проектированием урла для аппрува (хотя щяс ретроспективно не понимаю, что за трудности), а с другой стороны чёт захотелось поэкономить методы.

В итоге сейчас у нас есть метод PATCH /entity/{id}
который принимает сущность с 15 нуллабельными полями. используется двумя способами - либо присылаются все 15, либо 1 - approved

И есть метод POST /entity
С теми же 15 полями. но не нуллабельными.

И хз что с этим добром теперь делать.

Щяс я уже думаю, что надо было не выпендриваться, обновление делать через PUT, а аппрув через PATCH /entity/{id}/approved или POST /entity/{id}/(approve|reject)

А от PATCH-а сущностей держаться подальше до тех пор, пока требования к стенке не припрут - в языках со статической типизацией это боль

И заодно наткнулся на прикольную штуку JSON-P - когда мне придётся в следующий раз делать патч, я так пойду, а не через типизированную нуллабельную ДТОшку

#case@ergonomic_code #project_camp@ergonomic_code #http_api@ergonomic_code #rest_api@ergonomic_code #tools@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

Привет!

Джуг наконец-то опубликовал запись моего доклада о декомпозиции на базе эффектов с JPoint!:)

А ещё они мне подарили бесплатный оффлайн билет на Джокер:) Не знаю, сколько ещё продлится этот аукцион невиданной щедрости, но приятно.

В общем ещё раз рекомендую Джуг в качестве организатора конференций - теперь я ещё в чуть большем восторге:)

#talks@ergonomic_code #ergo_approach@ergonomic_code #effects_diagram@ergonomic_code #project_camp@ergonomic_code #case@ergonomic_code