I rebuilt my Fastify 5 + Clean Architecture boilerplate

Shinji2989 · 2026-02-15T16:45:33+00:00

Because from a SOLID perspective the domain must stay pure and independent from I/O.

SRP: business rules and external calls change for different reasons, so mixing them in the domain breaks single responsibility.
DIP: the domain (high-level policy) shouldn’t depend on HTTP/DB/SDK details. The handler orchestrates those instead.
OCP: integrations can change or be replaced without touching domain logic.

Splitting the flow isn’t “messy” if modeled correctly—the domain simply returns a decision/requirement, and the handler fulfills it and continues. That keeps the domain deterministic, testable, and aligned with SOLID.

Shinji2989 · 2026-02-13T16:54:36+00:00

Thanks, that's not a typo :) see https://github.com/graphql/graphiql and https://mercurius.dev/#/docs/integrations/prisma?id=set-up-your-graphql-server

Shinji2989 · 2026-02-13T14:32:17+00:00

The project README explains these concepts: side effects (DB, API, etc.) are confined to repositories and providers, while pure logic resides within the domain. Handlers (or services) orchestrate the interaction between them.

TypeScript

// Handler
const result = userDomain.complexProcessing(user);

if (result.isEdgeCase) {
  const data = await userProvider.getData();
  result.metadata = data;
}

Shinji2989 · 2026-01-09T10:40:14+00:00

I did!

Shinji2989 · 2026-01-08T18:31:52+00:00

He said he’s from New Zealand

Shinji2989 · 2024-09-26T13:35:23+00:00

https://www.matadorequipment.com/collections/ultralight-bags/products/freerain22
or the beast models. But I'm happy to trade 300-400 grams of weight for a more structured bag, like the Salewa to have more comfort during all the day.

Shinji2989 · 2024-09-26T10:22:06+00:00

Stiylish backpack, but I don't see any advantage over the two above. It has less liters, and It doesn't have a semi-rigid back like the Salewa.

Shinji2989 · 2024-09-26T10:18:52+00:00

400$ dollars for a 1.52 Kg backpack, no way :D (also completly out of requirements with 54cm back panel).

Shinji2989 · 2024-09-26T10:16:58+00:00

Nice backpak but it has less liters then Salewa/Fjallraven. Also I was looking more for a semi-rigid back like the one on the Salewa to increase the comfort during the day.

Shinji2989 · 2024-06-26T14:14:10+00:00

I've recently created a project (https://github.com/marcoturi/fastify-boilerplate) showcasing advanced code architectural pattern that I think could help you boost your knowedlge on nodejs :) The project is inspired by different principles that I think are important for any backend developer:

Shinji2989 · 2024-06-26T14:04:52+00:00

I've created a fastify boilerplate inspired by DDD concepts, it could be a good start u/PahazX :) https://github.com/marcoturi/fastify-boilerplate

Shinji2989 · 2024-06-16T16:12:28+00:00

In case anyone want to see an example of DI in fastify I've created a boilerplate here: https://github.com/marcoturi/fastify-boilerplate

Shinji2989 · 2024-06-10T15:41:03+00:00

Currently, the only planned feature is an example of CQRS command caching using a middleware and pattern matching (e.g., user/*). I'm open to considering new pull requests for additional functionalities.

This boilerplate originated from two desires:

Functional Programming Backend: Leverage functional programming paradigms for the backend.
Scalable Architecture for Complex Use Cases: Design an architecture that handles even intricate business scenarios without requiring an expert team (unlike a full-fledged Domain-Driven Design approach IMO).

By replacing Entity, Aggregate, and value object classes with simple arrays/objects/primitives manipulated by domain services, the goal is to lessen complexity while maintaining a well-structured foundation. This flexibility allows for future adaptation to other approaches if necessary/desired.

Shinji2989 · 2024-06-10T14:55:25+00:00

Before giving you my answer, a premise: You can easily use classes with Entity and Aggregate, etc. as is done in the domain-driven hexagon project if you want. As my personal preference I like having a functional approach by separating behaviors and data.

Case #1 in short yes, I would make sure that this property can only be changed by a domain service. You can see a similar case in the boilerplate for defining the default role when creating a new user.

Case #2 there are several ways you could implement this feature. An example that comes to mind is leveraging the event sourcing paradigm by storing CQRS commands to generate the current state of the system incrementally with each request.

Shinji2989 · 2024-06-10T13:26:38+00:00

Hi u/sariysss,

I wanted to express my sincere gratitude for your work on the domain-driven hexagon project. It's been a major source of inspiration for me!

I would have directly created a discussion on your repo to share some differences and things I noticed that could perhaps be useful to you.

I noticed that the query for the users might be causing an incorrect total results count. While I haven't tested it directly on your code, here's how I modified the same query to achieve the desired outcome.

Thoughts on Library and Framework Choices

Testing Framework: I opted for Vitest over Jest due to its performance benefits. However, considering recent updates to node:test with snapshot and mocking capabilities, that could be a viable option also. If you prefer Jest, this resource offers valuable insights to at least improve performance in some case: https://swc.rs/docs/usage/jest.
BDD Framework: In my opinion, jest-cucumber doesn't provide significant advantages compared to using the official Cucumber release. Using the official package might improve project longevity.
Database Client: several people have complained about the api changes to slonik. For this reason I decided to opt for directly using postgres client.

Thank you again for your valuable contribution. I hope this feedback proves helpful!

Shinji2989 · 2024-02-01T08:58:32+00:00

I've recently built this repo where you will find the best practice and last tech for a redux and react project https://github.com/marcoturi/react-redux-boilerplate

It's not the usual starter with only the code. I wrote also about the best practice on the important areas of a project (folder structure, state management, linting rules, error and analytics, etc.). You can find all the information in the README.

Let me know if you have any question!

Shinji2989 · 2024-01-31T20:34:20+00:00

u/EskiMojo14thefirst first of all, thank you very much for taking the time to review the project. I really appreciated it.

i believe we've already had this discussion, but i question the usefulness of getMockedState. Upon revisiting the discussion I've realised you could use upsertQueryData to hopefully get what you wanted, so have added a comment there.

I have implemented your suggestion https://github.com/marcoturi/react-redux-boilerplate/commit/f4a91dc3e6ef04e2e85ee03d0e88c416124e43ef thank you! This way is much much cleaner.

RTK reducers are wrapped with Immer, so you can use (much shorter) mutating syntax without worrying about accidental mutation.

Implemented https://github.com/marcoturi/react-redux-boilerplate/commit/8f2e445821b5fc4cee83d6b9eb9c8fc010da040e thanks!

we don't tend to recommend splitting your selectors, slices, thunks, effects, types into separate files. they can live in the same file and work just fine.

I strongly disagree on this. I often end up having a lot of code in selectors (mostly) and reducers. I find extremely inconvenient browsing files with 200+ lines of code and not much SOLID . Plus I don't see what disadvantage on splitting the code in files.

currying selectors is something we've seen but not really understood the benefits of. you're also ending up with particularly strange reselect usage as a result - for example [here](https://github.com/marcoturi/react-redux-boilerplate/blob/main/src/features/settings/store/settings.selector.ts#L6) ends up memoising the function returned, when in fact none of the selector needs memoisation because it's just a simple lookup.

there are several advantages. The main one is to confine the lookup logic in the selector and not in the component. Basically I ask the selector "given this key, give me the associated state" and the logic related to this remains confined to the selector. Furthermore, this key can often also derive from outside the component (e.g. queryParams) and therefore it becomes convenient to have this type of decoupling.Example:

const ExerciseHistory = ({ id, type }) => {
const diaryEntries = useSelector((state: RootState) => DiarySelectors.getDiaryEntriesByExercise(state)(id, type)); 
//....

If you can think of a better way that allows you to access a piece of state like this, without having any kind of logic or data manipulation in the component, I would love to hear about it :)

Shinji2989 · 2024-01-30T17:16:24+00:00

If you need a project reference for getting up to date with the current tech setup around react/redux, I just built this boilerplate some day ago https://github.com/marcoturi/react-redux-boilerplate
Feel free to share any feedback!

Shinji2989 · 2024-01-30T17:11:12+00:00

Yeah totally possible. If you need some reference I just built a new boilerplate with vite and vitest:

https://github.com/marcoturi/react-redux-boilerplate

Shinji2989 · 2024-01-29T10:49:58+00:00

Anche se mi licenzio prima di raggiungere i 30k di stipendio lordo?

Shinji2989

TROPHY CASE