I'm working on a project using Clean Architecture and an ORM. I have two entities: Entity A and Entity B. Entity A has a relationship with Entity B (e.g., Entity A contains an instance of Entity B).
When creating Entity A, I have the option to automatically create Entity B within the same use case. Alternatively, I could create a separate use case for Entity B, then use a facade or a coordinating service to first create Entity B, associate it with Entity A, and then create Entity A.
For example
class EntityA { entityB: EntityB}My Questions:
Which approach aligns better with Clean Architecture principles, and why?Should I use a single use case to handle both creations, or should I separate them and use a facade or service to coordinate the process?What are the best practices and considerations for handling such scenarios to ensure modularity, testability, and maintainability?Additional Context:
Using Clean Architecture principles.Entity A has a one-to-one relationship with Entity B.Employing an ORM for database operations.
I created separate use cases for creating EntityA and EntityB. I expected this approach to adhere to Clean Architecture principles by promoting separation of concerns and single responsibility. However, I'm questioning if this might be overengineering and if a simpler approach of combining the creation processes into a single use case would be more appropriate.
