Of course, it depends… how big the project is, how many teams, how complex the project is, what is the quality/technical debt and so on. You should find the best way to organize the work based on the goals and constraints of the project/ company.

• big project (many teams, many services), high cognitive load

In the case of a high cognitive load/amount of knowledge, there is no other way – you have to divide the entire problem space, the entire project into parts that teams can manage. But how to divide? Discover subdomains first How to discover (sub)domains, then assign services to subdomains based on the main responsibilities of the service, then assign/create teams for the subdomains. (btw. service may have responsibilities from different subdomains, so it should be refactored to match the domain)

The size of the team should take into account the subdomain size, complexity, stability, subdomain type, and future changes.

What if there are more subdomains than teams in the project? Try assigning a subdomain based on the main process flow:

If you haven’t discovered the subdomains yet, try to do so as soon as possible, but for now you can assign services along the main processes (for simplicity I present one process, but you should outline all the main processes.):

Subsequent services in the main processes depend on each other, which is why it is crucial to enclose as many as possible dependencies in one team.