Clean Architecture (Backend)

A microservice-architecture is not pursued (yet); as of now, modular monoliths will be implemented to start the new project. In each service a layered architecture will be applied.

  • The main GraphQL entrypoint is defined on service level.
  • Each service is structured into submodules (“features”). A submodule is a self-contained unit of
    • GraphQL-API-Endpoints: Queries and Mutations. They call the use cases to provide the response.
    • Use Cases are implementing the actual business logic by calling the services/repositories. Use cases orchestrate the services/repositories. The also serve as public interface to other submodules. Thus submodules could call use cases from other use cases, although it should be avoided.
    • Services are concrete operations and calculations upon models, which are not CRUD.
    • Repositories CRUD functionalities for models.
    • Models are the database entities.
    • see also:

Function-first vs feature-first

Function-first means that your project is structured by functions like actions, components, containers, modals, handler. However, there is the problem with scaling – it will become more and more difficult to maintain the overview since features are scattered through the whole codebase. Moreover, it usually violates the principle of locality (german: Lokalitätsprinzip): code which is executed together, should be also structured together.

Feature-first takes the whole other direction. The functions are scattered but the feature itself is self-contained and closed – actually the same structural approach you would choose for defining modules. In my experience this is a good way to structure an app which can easily scale – as long as (naming) conventions are defined on how the features/modules are structured. Inside a feature I would usually structure by function.

Article reference: (actually the article is about Ducks)