The Reviewer Says The Model Is Anemic
Decide what you would do from the brief alone, including whether you would change anything at all. Everything below it is available, but the exercise stops working if you open it first.
A design review blocks a module: PracticeNote is a data class with public fields, and PracticeNoteService does create, update, list and archive. The reviewer wants an entity with behaviour, value objects and an aggregate root. Decide.
Doing what the reviewer asked, because it is a small module and arguing costs more than complying. You get PracticeNote with private fields and getters, a NoteText value object wrapping a string, a NoteId wrapping a UUID, and a repository interface with one implementation. Every piece is defensible on its own and together they add four files and a vocabulary to a module that does four things. The damage is precedent rather than local cost: the next module copies the shape because it is now "how we model", and within a year the codebase has a uniform structure justified by a rule rather than by any rule of the business — which is the condition that makes the genuinely rich modules indistinguishable from the ceremonial ones.
Read this even if you are confident. It is here rather than behind a button because it is the answer most teams actually ship, it passes review, and the cost of it does not arrive until the change after this one.