dalrho/daibetes

1. This repository is split into two main deployable parts: a JavaFX desktop application in java-application and a separate Python AI inference service in python-ai-service. The Java side is the primary user-facing system; the Python side is an internal analysis boundary for model-based diagnosis.

2. The Java application is a modular desktop app built with Java 17+, Maven, JavaFX/FXML, and JDBC/MySQL. module-info.java and the many *.fxml views show a classic UI-driven desktop architecture rather than a web app.

3. The UI is organized around multiple portals and workflows: login/register, doctor dashboard, patient dashboard, image upload/camera capture, image processing, records, results, inbox, and report review. There are also several standalone launcher classes, which suggests each screen or feature can be started independently during development.

4. The newer, more structured code lives under org.example.daibetes, which contains the core architecture. That package is split into core (domain + database), modules (auth, detection, doctor, ai), and shared utilities. The flat top-level packages like login, register, patientsdashboard, and doctorDashboard look like older or parallel UI implementations.

5. The domain layer models the main actors and their relationships: User, Doctor, and Patient, with factory classes for object creation. This aligns with the README’s OOP goal of shared user behavior plus role-specific permissions and attributes.

6. Authentication and registration are isolated in modules/auth, with controller classes for doctor/patient registration and a LoginViewModel. Validation and password handling are centralized in shared/utils, which keeps credential logic out of the UI controllers.

7. Persistence is handled through core/database, which contains a MySQLConnection singleton-style connector plus DAO classes for specific areas such as doctor dashboard, patient dashboard, images, reports, and tests. The presence of generic CRUD helpers (CreateData, RetrieveData, UpdateData, DeleteData) and an SQL script (dbdaibetes.sql) indicates a relational MySQL-backed workflow for users, scans, and diagnostic records.

8. The retinal image pipeline is in modules/detection. It is divided into image preprocessing, camera capture UI, and a scan analysis service. The preprocessing layer uses a decorator-based design (BasePreprocessor, BrightnessDecorator, CLAHEDecorator, DenoiseDecorator, GrayscaleDecorator, ResizeDecorator, SharpenerDecorator), matching the README’s goal of chaining filters dynamically before analysis.

9. The AI boundary is explicit: AIInferenceService on the Java side corresponds to a standalone Python service containing inference_controller.py, dr_classification_service.py, model_loader.py, image_preprocessor.py, and a trained model file (diabetic_retinopathy_full_model.pth). This service is likely where image tensors are prepared and passed through the ML model, while the Java app stays responsible for orchestration and UI.

10. The Python service is layered too: API layer, application services, domain result objects, and infrastructure for preprocessing and loading the model. The presence of gemini_service.py and prompt_builder.py suggests an additional text-generation or narrative-report step alongside classification, which would feed doctor-facing summaries.

11. The doctor workflow appears to be: upload or capture retinal image, preprocess/analyze it, review the AI output, and generate/approve results for the patient. The doctor dashboard, generate-results screen, records, report review, and inbox screens support that approval-and-delivery loop.

12. The patient workflow is separate and simpler: authentication, dashboard access, and viewing finalized diagnosis/results. PatientDashboard*, records, results, and reviewResults form the patient-facing boundary for consuming approved reports rather than generating them.

13. The resource layout reinforces the UI architecture: each screen has its own FXML file, with CSS in styles/ and image assets in resources/images. That makes the architecture highly view-driven, with controllers acting as the glue between the FXML views and the services/DAOs.

14. For an architecture diagram, the key boundaries to show are: JavaFX UI/controllers at the top, domain and service layers in the middle, MySQL persistence below, and the Python AI service off to the side as an external analysis engine. The central business flow is image intake → preprocessing → AI inference → doctor review → stored result delivery to the patient.