[Refactoring] Define and Implement Domain Models and Repository Interfaces for Logging

[Rwatana]

Background

The objective of this issue is to define the core business logic and interfaces of the application using Clean Architecture principles. This foundational work is crucial as it sets the stage for the rest of the system, ensuring that the application’s logic is separated from infrastructure concerns and can be tested and maintained independently.

Goal

Define and implement the domain models and repository interfaces required for the logging functionality. This issue will be closed when:

• The logging.go file is created with the necessary domain models.
• The logging_repositry.go file is created with the repository interface definitions.
• All relevant business logic and interface definitions are complete and reviewed.

Approach

Overview (What, How)

1. Domain Models: Create the logging.go file to define the core domain models related to logging. This includes defining entities, value objects, and any domain services necessary.
2. Repository Interfaces: Implement the logging_repositry.go file to define the repository interfaces. These interfaces will be used by the infrastructure layer to implement data access and persistence.

Todo

• [ ] Define domain models in logging.go.
• [ ] Define repository interfaces in logging_repositry.go.
• [ ] Review and validate the domain models and interfaces for accuracy and completeness.
• [ ] Document the design decisions and update relevant documentation.

Deadline

09/21/2024

Parent issue

None

References

following repositry pattern expecting repositry

Notes

Ensure that the design follows Clean Architecture principles, focusing on separation of concerns and testability.

[Rwatana]

@nayuta-ai

I have a question regarding the pull request. I am currently working on an issue and have implemented the functionality in logging.go to store messages from RabbitMQ into a list. Additionally, I have created a simple test to verify the JSON conversion.

The implementation is about 34 lines, and the test is about 66 lines long. I am concerned that combining both into a single pull request might make it too large. However, I also believe it is important to include the test in the pull request.

In situations like this, what is the best approach? Should I include both the implementation and the test in one pull request, or would it be better to separate them?

[nayuta-ai]

Please split the implementation steps and provide the test item description for the pull request.