Thinking about design system is a practice of abstracting components, transforming them into reusable components, culminating in consistent, efficient code with a high level of scalability.
That means that it's a catalog with all reusable components, it can contain information about the use of these components and how to build their interfaces.

Atomic Design is a design system pattern, which aims to start from a base element and reach a more complex element, functioning as a living system.

BASIC ➡️ COMPLEX

“We’re not designing pages, we’re designing systems of components.” — Stephen Hay

Bringing it to development, we can paraphrase it as follows:
“We’re not building pages, we’re building systems of components.”

The basic structure of Atomic design is:
ATOM: Fundamental block, it is an HTML tag, for example an input or button.
MOLECULE: It is the joining of atoms with the aim of forming a functional unit or that represents a purpose. For example: Search or Form.
ORGANISM: It is the set of molecules, the organism contains more than one responsibility but brings together molecules with the same context. For example: Header, Footer, or Side Menu.
TEMPLATE: The template organizes the layout of the page using organisms.
PAGE: The page passes the data to the template and makes the organisms interact with each other, putting the system into practice.

Atomic design promotes solid foundations that are established from the beginning, with all elements being initially planned: fonts, color palette, avatars, buttons, etc.

When developing an application, even if initially the main focus is not on expansion or increasing complexity, it is still possible that at some point the application will reach a level of complexity at which common software development problems, so-called“code smells”.

Code smells arise when a series of development decisions result in a deep problem in the code.

We will solve two code smells using the atomic design methodology.

Repetition of components or services - DRY.
When there is a change in the development team and the design pattern is not consistent, components or services may be recreated in different contexts, which overloads the code and interferes with the application's performance.

For example:

And the component:

Resolution:

The components

CommentCount

and isLikesCount are almost the same, except for the properties, they can be unified into a single molecule, which is responsible for showing the number of items and using an icon that represents that item.

Excess of cascading properties in a single component.

It's difficult to understand components with a long list of properties. Furthermore, the more branched the properties passed to the component increase the ineligibility of the code, going against the purpose of clean code.

To solve this problem, we separate the properties that use the user as a base in a molecule called Avatar, and thus build the PostComment organism.

The Atomic design methodology can be expanded to frontend as a fundamental tool when addressing common software development challenges, such as code smells. Repetition of components or services (DRY principle) and an excess of cascading properties within a single component—can be effectively resolved through the application of Atomic Design principles. In addiction, is important to understand that frontend and design needs to have a symbiotic relation.

source:
https://bootcamp.uxdesign.cc/building-design-systems-with-atomic-design-fd21e86f34c5
https://bradfrost.com/blog/post/atomic-web-design/