Naming and structure in the Clean Architecture

[Zamith]

Hi,

I've been writing a blog application as a case study (more like an experiment) for the clean architecture. The problem I'm facing now is that I want to be able to perform CRUD actions on the Post entity, as would be expected, and so I have a use case (or service) class for each operation. Here's the file structure (it's in Ruby, BTW):

> services

  > creates_posts.rb 

  > deletes_posts.rb

  > gets_posts.rb

  > updates_posts.rb

Apart from naming the classes as verbs, which I like, my problem is that I fear I'm going to have to repeat this 4 file pattern for almost every entity. If I add comments I'm going to need to CRUD them, the same with tags, etc...

The solutions I can think of are moving the 4 files into a posts folder, which would create some order, but would just be hiding the problem, or move all the functionality into a single file called PostsController or PostsManager, both these names are smells for me, since usually they mean you're breaking SRP.

A final solution I thought of is to change the name of the outer package from services to ui (since it represents the ui port), and have a file called Posts or PostsAdapter. Still, I'm afraid this would be breaking SRP as well.

Can anyone think of a good solution for this? Is any of the solutions I proposed not as bad as I painted it?

Thanks,
Zamith 

  

[Uncle Bob]

I'm not convinced that your initial solution is a problem.  Every entitiy _does_ have CRUD, and so why wouldn't there be CRUD interactors for every entity?  

Now, certainly there's some common code in those interactors; but that just implies a base class, or a common strategy pattern.

What am I missing?

[Zamith]

Yes, maybe it was fine. It just felt odd, I wasn't sure if was being driven by the use cases, or not. But I guess it is ok like this,

Obviously I don't want duplication on the interactors, but that's a whole new story.

Thanks.