Я скажу, как бы я сделал на вашем месте, но не утверждаю что это "правильно", хотя для себя считаю именно так. Раз язык не важен, то скажу в контексте языка C#.
Если у сущности идентификатор является целочисленным типом данных и его значение присваивается на стороне БД, как в вашем случае, то до сохранения сущности свойство Id должно просто иметь значение равное нулю. После сохранения в репозитории свойству Id будет присвоено значение, которое для него сгенерировала база данных. Чаще для меня это не очень удобно, поэтому я выбираю использование глобального уникального идентификатора (GUID), который генерирую на стороне c#-кода (бекенд).
Ещё я бы исправил нейминг:
Вместо UserEntity написал просто User. Entity уже сильно избыточно, если вы определили его на уровне бизнес-логики (Domain, Business Layer и т.п.), то из контекста уже понятно что это сущность;
UserRepositoryProtocol. Если это интерфейс, а не реализация, то в C# пишем префикс I, т.е. IUserRepositoryProtocol. Не знаю как в Питоне, но по мне - Protocol лишний суффикс. UserRepository достаточно будет. Я бы выбрал [Имя сущности]Repository;
Имя метода create у репозитория не очень нравится. Да, такой нейминг встречается, но по мне вводит в заблуждение, т.к. вы здесь ничего не создаете - сущность уже создана и вы передаете её репозиторию для сохранения. Также репозиторий это не Фабрика, чтобы что-то создавать. Я предпочитаю коллекционный интерфейс, т.е. когда вы репозиторий рассматриваете как коллекцию и в таком случае лучше назвать метод Add вместо Create.;
Сергей Соколов, вполне себе хороший ответ, мне нравиться. Более-менее, что-то конкретное написано. Да, может он и не даст самый оптимальный вариант, но "самый" и не нужен.
Хорошо.
А такой вариант?
1. Сортируем файлы по размеру от самого большого, до самого маленького, т.е. по убыванию;
2. Берем первый (самый большой) файл и помещаем его в первую папку;
3. Далее начиная со второго файла перебираем все подряд и пробуем разместить его в 1-ой папке, если не получается, то тогда создаем новую, ну и т.д.
Думаю не будет преувеличением, если я вам скажу следующее: даже если вы прочитаете все книги по DDD, то сомневаюсь что вам придёт понимание того, как нужно писать программы. DDD - это скорее способ зарабатывания денег на этом, но ничего нового в нём нету. Возьмите лучше более старые книги, и вы увидите что в DDD это просто взяли и переименовали.
Конечно позитивный сценарий можно так и назвать "Выдача книг на абонемент". Но есть ещё множество негативных сценариев, например когда книгу взял уже другой читатель. Если книга имеет возрастную категорию, к которой читатель не принадлежит. Если количество книг превышает допустимый предел и т.д.
dollar, например сценарий выдачи книг читателю на абонемент. Примерно так: достать из базы абонемент, записать на него книги и сохранить в базу. Потом из базы достать абонемент и проверить все ли записалось в него. Как-то так я себе представляю.
Тоже с вами согласен. Хотя слышал есть понятие самоункапсуляция, и вроде как его придумал Фаулер, когда доступ к полям осуществляется через геттеры. Но вы все правильно сказали, что геттеры и сеттеры это публичный интерфейс.
Я скажу, как бы я сделал на вашем месте, но не утверждаю что это "правильно", хотя для себя считаю именно так. Раз язык не важен, то скажу в контексте языка C#.
Если у сущности идентификатор является целочисленным типом данных и его значение присваивается на стороне БД, как в вашем случае, то до сохранения сущности свойство Id должно просто иметь значение равное нулю. После сохранения в репозитории свойству Id будет присвоено значение, которое для него сгенерировала база данных. Чаще для меня это не очень удобно, поэтому я выбираю использование глобального уникального идентификатора (GUID), который генерирую на стороне c#-кода (бекенд).
Ещё я бы исправил нейминг: