Components in Clean Architecture

Question

I'm a novice in architecture. Now I’m reading Clean Architecture and I don’t understand one thing. I'm wondering at what stage should I create components? Before any design or when I already have some design and implementation, something like this:

P.S. It seems to me that the answer is somewhere in the middle. Components are designed to separate classes into groups so that different teams can develop them independently. That is, for this, some kind of design must already exist. And components are created using use cases, into which classes are then distributed. But these are my guesses

Answer 1

Clean Architecture in and by itself is just a way to organize code within a project and enforce a quite maintainable structure in a way that makes it easy to swap in and out implementations by changing the minimum amount of code.

In it's purest form, clean architecture is just a "divide et impera" framework

 presentation
      ↓
infrastructure
      ↓
 application
      ↓
    model

That's all. Eveything else is just a sovrastructure on top of this. Components fall into this category.

Now, let's assume your application is not contained within a single executable/project, and that your model is shared between multiple autonomous projects; maybe we're talking about an user model and all the necessary info to retrieve and modify such an entity (permissions, getUserById, isAuthorizedForSuch, authentication, GDPR): this information falls within the use cases of a component;

A group of functionality relative to a restricted group of strongly coupled models and functionality that evolve together: a permission entity is strongly coupled with an user entity, for example.

Components are a way to pack together and ship all the related models, business, database and and APIs for this functionality. now obviusly components do still need to depend on abstractions to query the database and such and be easily used.

On the "when do i think about componets" question: it depends.

• Fast initial development or an overall small service or application? Group it together later (if ever); components tend to emerge organically. If your code is based upon inversion of control and neatly organized and separated, extracting components will be an easy refactoring (generally speaking, it obviusly requires you to know where all the shit is in the first place).
• Microservices or large projects and teams (i'm talking 30+ people on the same project)? It'll be easier to think in components first, because from day one you'll need to share models between teams, and having to manually verify if the model in goofylolv1.js is compatible with loldidntknowhowtonamethis.js is not gonna be an easy task; but having to check if team A and B are using v1.1.1 of your MyComponent package is going to be way easier, especially in the initial development phase where the model will change very frequently and functionality will be added continuosly.

Answer 2

I'm wondering at what stage should I create components?

Once you’ve thought of a name.

The single most important thing for a component is its name. The name should make clear what does and doesn’t belong inside. It should make finding things easy.

This is as true for clean architecture as anything else. First and foremost these boxes you dump code into need clear labels.