Да, он не плоский, он линейный, последовательность символов

HATEOAS, REST-клиенту не требуется заранее знать, как взаимодействовать с приложением или сервером за пределом гипермедиа.

это подразумевает что предметную область данных можно понять из их структуры и структуры uri

А каким боком тут сеарилизованое представление?

это к тому что если слать плоские объекты вместо нормально структурированных и думать об этом как о том что мы скрываем предметную область - получится хрень

по этому правильным решением будет сделать PUT user/name либо через вложенный объект, ну выбор очевиден

Когда у меня бывшая писала свой первый сервер на хаскеле, она задала мне столько вопросов о том как же всетаки правильно готовить rest, что отвечая на них я понял, что ответ как правильно готовить rest - не готовить rest =) слишком мало ограничений

Пока изоморфизм есть, предметка не скрывается

“Когда у меня бывшая писала свой первый сервер на хаскеле”

ну может это и нельзя назвать сокрытием, но предсказательная сила фронтендеров не так велика, особенно когда дело доходит до предметной области) всетки опыта в ней меньше(меня вот бесит когда на фронт отправляют плоские объекты с 100 полей, а я должен по ним понять как их смапить)

Можно пошутить, что ФП передается половым путем, потому что я тоже попробовал.

Поэтому и "бывшая" 😂

почему? REST, Haskell — одни достоинства

Подскажите как правильно понять Domain Model какая она должна быть для такого примера:
Есть два списка доходы и расходы, предполагается еще несколько, но не сейчас, например, кредиты
Так же опционально для A/B тестов каждый список может иметь фичу: папки, куда можно складировать эл-ты списка или папки.
Как я это представляю:
1. Очень конкретные модели: модель доходов, модель расходов и функционал в каждой, папки либо что-то полиморфное для любого списка либо отдельно для каждой. Но это как-то очень много кода.
2. Абстрактно: список + папки и потом уже на уровне сервисов, наверно, конкретизировать доходы и расходы

3. Найти ментора из финтеха который знает предметную область.
Это будет стоить денег, но хотябы людей не подставишь.

еще упростим. Todo list два списка дела с картинками и дела с текстом, надеюсь тут все спецы в предметной области

Реализация гроссбуха чутка сложнее Тодо листа и там есть свои нюансы. Потому и говорю. Найми консультанта. Напортачишь же 100%.

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

Для DDD важны операции, а не просто список списков

понятно, я отметил: + функционал.
Наверно очевидно, что для списка и папок функционал понятен: создать, удалить, редактировать + для папок добавить элемент, удалить элемент

По большому счету вопрос в том как сделать папки безболезненно отсоединяемыми/выключаемыми
Да и что конкретно должно быть в модели и на каком уровне разграничивать типы списков.