Project Architecture

The Rest api architecture build with a clear separation between different layers of the application, adhering to the repository pattern to isolate the data layer from the REST API layer. Utilizing the repository pattern significantly enhances the flexibility and maintainability of an application by decoupling the data access logic from the business logic layers. This abstraction allows us to change or extend the data access logic without impacting the rest of the application, making it easier to adapt to new business requirements or data sources.

The application is organized into distinct directories, each serving specific roles—from managing core functionalities to handling API requests and providing web interfaces. This structure not only facilitates a clean separation of concerns but also enhances modularity, testability, and the maintainability of the codebase.

• /core : Central repository for shared logic, models, and database connection utilities, ensuring DRY principles are adhered to across the application.

• Models: Define data structures used across the application.
• Repositories: Abstract data access, facilitating easy switches between different database technologies.
• Connections: Manage database connectivity, centralizing connection logic for reuse and maintainability.

Central to the architecture is the Repository Pattern, implemented within the /core/repositories directory. This design pattern abstracts the data layer, providing a collection-like interface for accessing domain objects. It separates the logic that retrieves data from the database from business logic, minimizing direct dependencies on the data source.

• Abstraction of Data Access: Allows the business logic to interact with a repository interface, rather than directly with the database, fostering a loose coupling between application layers.
• Exchangeability of Data Sources: Simplifies the transition between different databases or data storage methods with minimal impact on the application logic.
• Improved Testability: Facilitates unit testing by allowing mock repositories to be used in place of actual data access code.
• Consistency in Data Access: Offers a centralized location for data operations, ensuring consistency in how data is queried and manipulated across the application.

• /taxon_search_api and /crud_api : Host RESTful endpoints for taxonomy search and CRUD operations, respectively. Each API module contains its services directory, segregating business logic from HTTP routing concerns.

• Separation of Concerns: Distinct handling of HTTP requests and business logic.
• Testability: Simplifies unit testing of business logic without Flask context.
• Reusability: Business logic can be reused across different parts of the application or in different contexts.

• /public_web and /staff_web : Provide user and staff interfaces for searching taxonomic data and performing data management tasks. These are developed with clear separation from the API logic, ensuring that the web layers serve purely as presentation layers.