If you've read the previous note, the keen-eyed among you might have noticed that the domain folder mentioned in the directory restructuring plan did not appear in the final refactoring results.
This is because domain modeling is a relatively challenging task that requires long-term effort and careful consideration. So, we don't rush it. Starting from this note, we will delve into related content.
Before diving into the actual refactoring exercise, this note will first explain the importance of the domain folder. Please grab your seats and pay attention as I explain.
In the modular directory structure I designed, there are three core top-level folders: shared, domain, and entry, each serving the following purposes:
-
shared: Contains universally used assets, styles, and functions that have no business logic and are applicable throughout the entire application. -
domain: Houses assets, styles, and functions related to specific business logic, without being restricted by the development framework or page routing. -
entry: Serves as the application's initialization and page rendering "entry point", which is constrained by the development framework and page routing mechanisms.
The domain folder is the cornerstone of this structure—most of the application's logic resides here, making it crucial. In contrast, the other two folders are relatively lightweight, especially the entry folder.
Since the official website project I inherited uses Next.js, its prescribed app folder serves as the entry folder.
Many front-end developers have a superficial understanding of "modularization", thinking that simply moving a piece of code into another file and referencing it elsewhere (e.g., encapsulating utility functions or UI components) constitutes modularization. While this approach has some benefits, it doesn't significantly enhance application development. Modularizing business logic is where the real power lies—this is where domain modeling comes in, a skill that many front-end developers lack.
The subfolders within the domain folder represent abstracted business modules, each strictly adhering to the principles of "high cohesion and low coupling". Each module contains only code related to its own business logic, with clear semantic declarations of dependencies on other business modules.
The directory structure of a business module typically looks like this:
If, like in most projects, files are indiscriminately thrown into global folders such as services or components without any abstraction, the most immediate problem encountered is the need to sift through numerous subfolders to identify the files that need modification. This process must be repeated every time you switch between different categories of folders, making it difficult to focus and severely impacting efficiency.
This is because organizing files by category forcibly disassembles files that are closely related from a business perspective—it's like breaking up a pair of lovebirds!
Without abstracting and reusing modules based on business logic, the dependencies between UI components and pages can easily become extremely convoluted, eventually turning into an intractable mess that further affects development efficiency and application quality.
The domain folder in my modularization model is the perfect remedy for this issue, acting like different-colored cable ties that neatly organize and constrain the "wires", bringing order to the entire application.
Moreover, ideally, each business module within the domain folder can be reused in different applications—just like general-purpose modules installed via npm!
What do you think? Have you grasped the benefits of the modularization model and the importance of the domain folder?
Top comments (0)