Refactoring notification module

[rootwarp]

• Parents: Refactoring to remove "interface" types #125

---

Checklist

• New Feature for the SVC/Plugin
• New Feature for CI/CD
• Enhancement on Vatz
• Others(etc. e.g, documentation,...)

---

Please describe, what it's about or related Problem with

A clear description of what feature need to be developed or enhanced in Vatz

Refactoring issue starting from #125.
In this issue, Notification module will be refactored.

Describe the output that you are expecting for above

A clear and concise description of what you expect to happen.

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Additional context

Add any other context or screenshots about the feature request here.

[xellos00]

@rootwarp

For PR

• Refactoring notification module. #182

I am curious how you are going to manage business logic separation in the structures.
We put manager_layer in the module structure in purpose to separate business logic and module itself when started basic structure.
It wasn't optimized in first hand, but still I feef it's need.
do you plan to another layer for this.
because I don't want to call notification function from executror.go
please, let me know if you have another plan for this or further discussion need.

[rootwarp]

@xellos00 We don't need stay in business logic layer model like Java does.
We could just care about how we separate module from the others.
For that, exposing just only selected function is key part to separate as you said
and those subject can be possible as we expose just interface as well.
So I tried to use interface type from outside of module.

Does this make sense to you?

[xellos00]

@rootwarp
There seems to be more of a gap than what we talked to each other in the meeting regarding the refactoring issue.
I thought it's tasks to change sort of map[interface{}]interface{} into clear structures.
I understand your point as well that expose only selected in interface, yet there's still doubt on this due on complete separation

I don't think it's not only on Java, some practical framework in Go

• https://github.com/zeromicro/go-zero

let's have a further discussion for this, once we settle for 1st structure, guess it wouldn't be altered for long time
@hqueue Can you join to meeting?

[rootwarp]

@rootwarp There seems to be more of a gap than what we talked to each other in the meeting regarding the refactoring issue. I thought it's tasks to change sort of map[interface{}]interface{} into clear structures. I understand your point as well that expose only selected in interface, yet there's still doubt on this due on complete separation

I don't think it's not only on Java, some practical framework in Go

• https://github.com/zeromicro/go-zero

let's have a further discussion for this, once we settle for 1st structure, guess it wouldn't be altered for long time @hqueue Can you join to meeting?

Yup I removed some manager structure because of some issues.

1. Manager structure seems just simple wrapping up and even the instance from the manager is cross correlated from the outside. that makes coupling.
2. For testing. we totally need to use interface, so I re-defined interface and used for decoupling module.

As you said, Golang also need fancy architecture to build huge application.
But those should be done by module unit.