react-atomic-design VS modular-monolith-with-ddd

https://github.com/danilowoz/react-atomic-design maybe this as an example

Once I started learning about software development best practices such as the SOLID principles, Atomic Design, abstraction and design patterns my first instinct when writing any piece of new code was to write beautiful code from the very beginning. I wanted to make sure that my code was readable, maintainable, and scalable. However, I quickly realized that this approach was not only time-consuming but also led to frustration. I was spending too much time trying to make my code look perfect, and not enough time focusing on getting the job done. This got worse when I started working on larger projects with more complex code and TypeScript, where typing can be a bit tedious for reusable components.

2. React Atomic Design

React's biggest selling point is _declarative composability_. If you want to split functionality into other components, _just make other components_. It is common (and probably best) practice to design components [atomically](https://danilowoz.com/blog/atomic-design-with-react). If you need to share state between them, _hoist that state to a common ancestor_ component and pass it down through props. If you need props from a much more general location, you can look at using contexts, although be careful about this as they have some significant drawbacks.

I feel like this frees you up to use things like Atomic design with your components, which helps on the more folder-structure side of things.

Link to PR here: https://github.com/kgrzybek/modular-monolith-with-ddd/pull/286

- https://github.com/kgrzybek/modular-monolith-with-ddd (a really well documented example)

You can see there is a module called building_blocks. Inside it, I keep all the utilities needed in the project, like a logger, serializers, and so on. I did not make up this name, I borrowed it from this repo.

9. Modular Monolith with TDD

This covers far more than just DDD, however, I find the links and README super helpful for a wide range of subjects: https://github.com/kgrzybek/modular-monolith-with-ddd

Modular monolith. Here is one of the best production-ready examples https://github.com/kgrzybek/modular-monolith-with-ddd

Am wondering what react community thinks of DDD.

I've been reading "blue" DDD book (by Eric Evans) and "red" book (by Vaugh Vernon) and that was a completely "my whole life was a lie" type of experience and relief at the same time. It's just so great to have the principles of who to structure the code. It, by definition makes, your codebase structure meaningful. Because it's structured according to some common knowledge, not your random thoughts at the time you were writing code.

I was surprised to find so little DDD react sample codebases. Let's say for backend there is huge amount of samples, i.e. https://github.com/kgrzybek/modular-monolith-with-ddd . For react/frontend I have bookmarked only https://github.com/talyssonoc/react-redux-ddd/tree/master/sr... and few more, but those others does not meet the optional criteria i like really much - at the highest (or at app) level all codebase need to have folders app, domain, infra and ui. Simple rule, but simplifies life a lot.

So my question is - is DDD for some reasons not very applicable for app frontend development. Or it just never became popular. Or maybe DDD is popular amongst react developers, just I am not aware of this.

Many thanks for any ideas and comments!