DrEcho ADRs

What is the issue that we're seeing that is motivating this decision or change?

What is the change that we're proposing and/or doing?

Deciding between simple MVC and more complex MVVM for frontend architecture.

Choosing MVVM for its improved maintainability and adherence to SRP.

Deciding between MaterialFx and AtlantaFx (GH Primer implementation) for styling.

Choosing AtlantaFx, because it works fine, looks good, and doesn't add dependency like MaterialFx.

Need for demo implementation for: - presentation MVP - testing

- Implement standalone service layer with in-memory fake repositories. - Implement functionality to switch initializing with random business demo data.

- Weak entity code handling. - Difficulty in maintaining current classes during functionality implementation.

- Lombok can only be used in the client view layer. - Services and repositories will utilize Java Records.

- The app is growing. - Prevents tight coupling between layers for easier maintenance and testing. - Helps clean up layers.

Use ArchUnit to enforce clean architecture.

Need to standardize bundle key conventions.

Use pattern like this: <module>.<feature>.<action> Example: `ui.patient.record.save-patient-button=someValue`

Dependency injection of bundle instances is inconvenient. The client always has one bundle pack for the current instance.

Utilize a static class to manage ResourceBundle instances. Wrap the ResourceBundle class functionality. This decision allows for easier access and management of ResourceBundle instances within the application.

Need to standardize business object mapping.

Use three types of mappers: Client Side, Backend side for ServiceLayer <-> Domain, and Domain <-> PersistenceLayer.

Need some guidelines for UI exception handling.

Standardize UI error handling for client exceptions to ensure consistency and improve the predictability of exception handling across the application.