CODEWITHSUNDEEP
entity-relationshipsoftware-designclean-architectureuse-caseseparation-of-concerns
isaac
isaac

Reputation: 11

Related entity creation use case in clean architecture

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.

Upvotes: 1

Views: 71

Answers (1)

Gerd
Gerd

Reputation: 2813

From my point of view, the use cases perspective is generally different from the data model:

When defining entities, you have things like their resonsibilities and entity relationships in mind. When defining use cases, you think of the user's (actor's) goals and of preconditions and postconditions.

So it might make perfect sense to define a number of entities and there might still be a single use case that always has an impact on two or more of these entities.

Thinking of modularity and maintainability, you should probably consider if EntityB may ever exist independently of parent EntityA or if the type of relation may ever change (e.g. from a 1:1 to a 1:n relation) in a future extension of the system. If not, maintainability is probably better if the code is kept simple. :)

Upvotes: 0

Related Questions