(хотя загоняться по бесполезным аббривиатурам обычно проще чем следить за зависимостями и связанностью)

как следить ? тулзы по типу Кодеклимат или phpmetrics ?

жизненный цикл есть там где есть мутация стэйта. Там где есть мутация стэйта нужно контролировать инварианты этого стэйта. Потому нужна сущность. Как ты чего при этом дробишь уже не важно

Если вы так считаете, то мне даже лень спорить с вами

ну о чем и речь
что сущность !== «тупо дата-объект с геттерами-сеттерами» по определению

опять же важный момент что вся логика завязанная на работу со стэйтом должна быть в этом случае внутри этой сущности

У интерфейса сущности стейта нет - логика завязана на работу с интерфейсом, а не со стейтом

вы разделяйте уже нормальное определение слова «сущность» и то, что доктрине
вы щас о каком?

есть хитрости. То есть бывают кейсы когда структура данных одна и та же и надо это как-то мэпить на базу а поведение отличается. Кто-то пытается это решать через table inheritance кто-то еще как.

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

то есть в терминах любителей джаваскрипта чето типа

// service.ts

export function doSomethingWithEntity(entity: EntityState) {
    // do something
   return {...entity}
}

Что значит "нормальное"? Сущность может быть любым типом: стрингом, объектом, функцией, да хоть всей вселенной. Главное - интерфейс работы с ней

ОК, так и запишем
Сущность - это любой тип с интерфейсом ))

со звездочкой что сущность всегда должна оставаться валидной и интерфейс этой сущности (контракт) не должен допускать того что бы она вошла в невалидное состояние.

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

https://en.wikipedia.org/wiki/Domain-driven_design

Entity
An object that is not defined by its attributes, but rather by a thread of continuity and its identity.

- всегда валидное состояние уже сказали
- собственная идентичность
- жизненный цикл

вот и определение по сути

Ну, это уже проблемы сущности, а не сервиса, который исползует публичный интерфейс

обычно скажем в чем аргументы тех же любителей джавы в спорах с любителями ФП:

вот есть у тебя некий стэйт: type SomeEntity = {id: string, name: string}

И есть функция по работе с этим стэйтом:

function doSomethingWith(entity: SomeEntity) {
    // ...
}

мол мы можем написать еще одну функцию которая не будет учитывать каких-то инвариантов системы.

Только в случае с ФП ты можешь за счет алгебраических типов задавать какие-то переходы по стэйту и каким функциям с чем можно работать. За счет этого ты связываешь логику и стэйт.

В джавках единственный способ это сделать - положить все в один класс

тут важно что если у сущности интерфейс вида setPublished(isPublished: bool) то нахер нужен такой интерфейс

и спор в основном потому что "обычно" люди именно это подразумевют под интерфейсом сущностей

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

простой способ проверить адекватность интерфейса - если у тебя твой сервис достает что-то из сущности что бы принять решение - говно интерфейсы. Подавляющее большинство именно это представляют когда говорят о отношениях сервисов хранящих бизнес логику и сущностях