Frontend Clean Architecture

This is a forked version from this repository frontend-clean-architecture.

There are some extra features:

• Modular structure and aliases. Attempting to have better code spliting.
  • app: depends on all other modules
  • core: all modules depends on core module in order to access user, notification.
  • auth
  • cart
  • front
  • order
  • payment
• Refactor to react-router-dom 6.X
• Persist user and cart into local storage

---

Other languages: Russian.

A React + TypeScript example app built using the clean architecture in a functional(-ish) way.

• Working app
• Huge post about it

Things to Consider

There are a few compromises and simplifications in the code that are worth to be mentioned.

Shared Kernel

Shared Kernel is the code and data on which any modules can depend, but only if this dependency would not increase coupling. More details about the limitations and application are well described in the article "DDD, Hexagonal, Onion, Clean, CQRS, ... How I put it all together".

In this application, the shared kernel includes global type annotations that can be accessed anywhere in the app and by any module. Such types are collected in shared-kernel.d.ts.

Dependency in the Domain

The createOrder function uses the library-like function currentDatetime to specify the order creation date. This is not quite correct, because the domain should not depend on anything.

Ideally, the implementation of the Order type should accept all the necessary data, including the date, from outside. The creation of this entity would be in the application layer in orderProducts:

async function orderProducts(user: User, { products }: Cart) {
  const datetime = currentDatetime();
  const order = new Order(user, products, datetime);

  // ...
}

Use Case Testability

The order creation function orderProduct itself is framework-independent right now and can't be used and tested in isolation from React. The hook wrapper though is only used to provide the use case to components and to inject services into the use case itself.

In a canonical implementation, the function of the use case would be extracted outside the hook, and the services would be passed to the use case via a last argument or a DI:

type Dependencies = {
  notifier?: NotificationService;
  payment?: PaymentService;
  orderStorage?: OrderStorageService;
};

async function orderProducts(
  user: User,
  cart: Cart,
  dependencies: Dependencies = defaultDependencies
) {
  const { notifier, payment, orderStorage } = dependencies;

  // ...
}

Hook would then become an adapter:

function useOrderProducts() {
  const notifier = useNotifier();
  const payment = usePayment();
  const orderStorage = useOrdersStorage();

  return (user: User, cart: Cart) =>
    orderProducts(user, cart, {
      notifier,
      payment,
      orderStorage,
    });
}

In the sources, I thought it was unnecessary, as it would distract from the essence.

Crooked DI

In the application layer we inject services by hand:

export function useAuthenticate() {
  const storage: UserStorageService = useUserStorage();
  const auth: AuthenticationService = useAuth();

  // ...
}

In a good way, this should be automated and done through the dependency injection. But in the case of React and hooks, we can use them as a “container” that returns an implementation of the specified interface.

In this particular application, it didn't make much sense to set up the DI because it would distract from the main topic.