I don't know the structure of your domain, or what other domain objects you have, but have you thought deeply about how you are structuring your code.
At some level it makes sense that you or I could create a book. Creating a book isn't the same as publishing one. For example, I could write a memoir and never get it published.
With that in mind, would it be ...
If the business requires that you store an additional field/column of data, then there are essentially three possibilities:
You modify the code to require the new field but don't touch the old data. This effectively renders the existing data inaccessible which is not likely to be accepted by the business.
You write the reading code such that it can handle ...
It seems you are overthinking this. The advice is illustrated in a few different and related use cases.
1. User Submits Proposal: Use case where the user is responsible for ensuring Proposal is consistent. In other words, it is considered the user's responsibility to cause a consistent outcome of data mutation.
(A) User defines a Proposal and submits it to ...
No, don’t reuse aggregate root keys for identifying different objects in different contexts !
Because a Notificant is not a User. Maybe today, mostly users get notified. But tomorrow you may have to notify third parties who are not using the system, or even automatic monitoring systems.
Because it’s another bounded context, and bounded contexts may ...
The application uses JPA/Hibernate for persistence. The current behavior is that all aggregate roots are fetched from the database, updated by the application and then written back to the database with lots of update, delete, and insert statements.
Doctor, doctor, it hurts when I do this. - Well, don't do that.
ORMs will never figure out the use-case you're ...
You really need to decide:
Either Message is an independent aggregate root, and it has an independent unique Id,
Or Message belongs to the Chat aggregate, in which case it depends on Chat and is accessed via the aggregate root.
Using a composite key is in reality a mean to implement the latter. A composite key for Message that builds on Chat's Id would ...
Although a composite key is not a bad practice, I would recommend you to use a UUID.
Lets consider an UUID v4, for example, that is generated randomly:
The number of random version-4 UUIDs which need to be generated in order to have a 50% probability of at least one collision is 2.71 quintillion [...]
Source: Universally Unique Identifier -