Папка = buisness capability

Понял.
Спасибо.

Подскажите

Разбираюсь с ооп
Вот у меня есть entity, у неё есть id
Но его нет пока он не будет выдан базой. Какой должен быть id, когда я создаю сущность в сервисном слое, для последующего сохранения это entity в репозитории? Вопрос не конкретный а общий даже, в какую сторону читать

казалось бы, при чём тут ооп

UUID

Если id == null, то репозиторий делает insert, если id != null, то репозиторий делает update.

Айди можно получить заранее и передать в сущность когда ее собираешь. Если база поддерживает секвенсы то можно сначала у нее запросить. Если нет то из удобных вариантов только uuid

В этом случае стэйт невалиден.

Например,в spring'е такая реализация репозитория:
   /*
   * @see org.springframework.data.repository.CrudRepository#save(java.lang.Object)
   */
public <S extends T> S save(S entity) {
   if (entityInformation.isNew(entity)) {
       em.persist(entity);
       return entity;
   } else {
       return em.merge(entity);
   }
}

   У entity есть атрибут isNew

/**
* @see org.springframework.data.domain.Persistable#isNew()
*/
public boolean isNew() {
   return null == getId();
}
В этом случае стейт вполне валиден.

Эт понятно, гугли save your repositories from save

как этого избежать?

я про utils/shared/core утилитарные модули с функциями вроде lodash в js

Разбираться с cohesion. Учиться определять разные его вариации/типы и прикидывать какой вариант тебе где нужен.

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

я именно о либах вроде lodash'a

это же нормальная практика?

тут больше вопрос папочек похоже

Ну тут по сути надо понять зачем.

Какие у нас есть вещи на которые структура проекта влияет:

- некий discoverobility - где мол найти вещи которые тебя интересуют в рамках задачи. Тут можно ещё разбить на разные варианты зачем ты ищешь штуки. Чаще всего это "реюз" но реюз тоже разный бывает:

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

В случае lodash ты как пользователь оной заинтересован только в последнем. И для этого ты не папочки смотришь а документацию. То есть структура проекта на этот момент мало влияния оказывает

Есть ещё "а куда ложить новое", есть "а как трекать/форсить зависимости", "а кто за что отвечает" (code ownership). Вот для этих вопросов утилсы и кор с шаредами не выгодно. Но если проект маленький и в целом "команда полностью владеет кодом на равных" то мы можем упрощать структуру оптимизируя вопрос "куда класть". Потому так часто можно увидеть структуру проекта организованную по technical conserns. Думать меньше с таким приходится, любой новый разработчик быстро поймет чё куда класть. На больших проектах другие вопросы будут в приоритете. И "для реюза" так же будут доки и всякие там сторибуки с документацией, всякие дизайн системы гайдлайны

При этом на добьших проектах дешевле дублировать код (правило трёх) чем потом сражаться с херовыми абстракциями и каплингом

UUID - это выход. Но мне интересно. А если в базе ключами являются auto increment integer-ы? Вообще сущность без id - это нормальная ли практика? Ведь экземпляр сущности это что-то, что всегда отличается от другого экземпляра этой сущности, а если будут две несохраненные в базу сущности, то в коде невозможно будет их отличить, что противоречит правилам ООП. Неужели концепция incremental id не укладывается в ооп?

Autoicrement id это артифакт persistence слоя. В вашем домене вы как отличаете сущности друг от друга? Вот если бы все было в памяти, вы бы какой id выбрали?

Доменные сущности и их жизненный цикл, вообще говоря, не должны зависить от способа хранения данных.