Data duplication is a standard technic in the NoSQL world. Simply SQL normalization approach (third normal form etc) is not efficient on modern hardware where CPU (not storage) is the most expensive component. So you are good here.
The only question is how are you going to handle transactions and consistency (do you need strong consistency or just eventual consistency is fine). I hope your Spring chained transaction will do the job.
You could also look at it from a different angle and don't use transactions at all - just deal with EC data (it depends on your use case but worth mentioning that it is still an option). The second approach will be useful in distributed systems (SOA/microservices) but here I got the impression you have monolith.
Re DDD concern,
You do your design correctly. It's fine to create a separate module/service (or few) for reads and a separate one for writes. It's called Command Query Responsibility Segregation and helps a lot.
A real-world example for such an approach:
Imagine searching user in Users SQL table. You can search the user by name or id in SQL pretty easily. But doing a more advanced search (e.g. multi-column search with %pattern% ) is not efficient and tricky (imagine users have a lot of searchable columns like "job_title", "department", "team", "hobby" etc.) It would be great to provide separate services for advance searching (based e.g. on Elastic search).
Looks like you have a similar use case so I hope it will help set your mind.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Data duplication is a standard technic in the NoSQL world. Simply SQL normalization approach (third normal form etc) is not efficient on modern hardware where CPU (not storage) is the most expensive component. So you are good here.
The only question is how are you going to handle transactions and consistency (do you need strong consistency or just eventual consistency is fine). I hope your Spring chained transaction will do the job.
You could also look at it from a different angle and don't use transactions at all - just deal with EC data (it depends on your use case but worth mentioning that it is still an option). The second approach will be useful in distributed systems (SOA/microservices) but here I got the impression you have monolith.
Re DDD concern,
You do your design correctly. It's fine to create a separate module/service (or few) for reads and a separate one for writes. It's called Command Query Responsibility Segregation and helps a lot.
A real-world example for such an approach:
Imagine searching user in Users SQL table. You can search the user by name or id in SQL pretty easily. But doing a more advanced search (e.g. multi-column search with
%pattern%) is not efficient and tricky (imagine users have a lot of searchable columns like "job_title", "department", "team", "hobby" etc.) It would be great to provide separate services for advance searching (based e.g. on Elastic search).Looks like you have a similar use case so I hope it will help set your mind.