When you’re developing an Enterprise Application which will only be used by the company and its employees. You’re not building a global scale application, or you don’t have a case for scalability. You don’t need Micro-services and all the infrastructure complexities that comes with it. You still need to have good foundations in place for your application. And if the time comes you can break the pieces into separate services easily. This article aims to expand upon the proposal presented in “Components of Enterprise Software: Practical Case” concerning folder organization based on the concepts of Clean Architecture and Hexagonal Architecture. Here, I will propose a more elaborate folder structure than the one presented in the previous article. It should be noted that Clean and Hexagonal architectures do not pertain to folder organization, but rather to a logical abstraction of software components, their responsibilities, and their dependency relationships. Key Aspects to Consider The folder organization should align with software design concepts, with a crucial emphasis on application maintenance over the long term and the ability to evolve or scale with minimal effort. Separation of Concerns: The folder structure should reflect the principle of separation of concerns, grouping different components or layers of the system based on their responsibilities. Layered Architecture: Organize based on different layers, such as the presentation layer, business layer, and data layer. Functional Modules: Identify functional modules of the application and organize folders accordingly. Each module should have its folder with its components, such as controllers, services, models, and views. Code Reusability: The folder structure should promote code reusability. Identify common or utility components that can be shared across different parts of the application and place them in separate folders or modules. Scalability and Growth: Consider scalability and future project growth. The folder structure should be capable of accommodating new features, components, or layers without becoming excessively complex or confusing. It should facilitate the addition or modification of functionalities as the project evolves. Naming Conventions: The structure should follow clear and consistent naming conventions for folders and files, making code navigation and understanding the purpose of each folder or file easier. Configuration and Resources: Separate configuration files, static resources (such as images or style files), and other files unrelated to the source code into appropriate folders. Collaboration and Team Structure: Consider the development team’s structure and how they collaborate on the project. The folder structure should align with the team’s workflow and facilitate concurrent development, version control, and code review processes.