Maintenance: refactor `Metrics` types and interfaces to improve consistency and clarity

[dreamorosi]

Summary

Review all type and interface definitions and usage throughout the codebase to identify opportunities for refactoring and clean up. This will help improve consistency in naming, structure, and usage of types across the project.

Specific areas to investigate:

• Inconsistent naming (plural vs singular, capitalization, abbreviations, etc.)
• Misnamed types that are not actually types but constants or enums
• Usage of any where more specific types could be defined
• Opportunities to convert usage of enums to as const types
• Inheritance hierarchies that could be simplified
• Re-organization of types into more logical modules/namespaces

Why is this needed?

As the project has grown organically, inconsistencies in how types are defined and used have emerged. By refactoring and cleaning these up, we can improve maintainability, clarity, and reliability of the codebase.

More consistent and intention-revealing names will also improve onboarding and comprehension as well as DX.

Converting usage to proper types where applicable will enable stronger compiler checking and editor tooling support. Overall, this refactoring will leave the code in better shape for continued development and maintenance.

Which area does this relate to?

No response

Solution

Examples of types/interfaces/objects that could be improved:

• MetricsInterface (here) should be moved to the types folder as well as documented via comments
• MetricResolution (here) should be moved out of the types and into the constants.ts file since it's not a type
• MetricUnits (here) should be moved out of the types and into the constants.ts file since it's not a type, also the name should be made singular i.e. MetricUnit
• HandlerDecorator (here) could probably be moved into the commons package and reused elsewhere, since we have a copy at least in another package (Tracer)

---

Important

Before starting to work on a PR for this issue, the assignee should do an investigation of the code and propose an action plan under this issue.

Once the plan has been discussed and agreed upon with at least one maintainer work on the PR can start.

Acknowledgment

• This request meets Powertools for AWS Lambda (TypeScript) Tenets
• Should this be considered in other Powertools for AWS Lambda languages? i.e. Python, Java, and .NET

Future readers

Please react with 👍 and your use case to help us understand customer demand.