Refactor Plan

[TremblingV5]

There're some plan for refactor DouTok. If you have some advices, please comment here.

Also, welcome to select one or more entries to do something and that's DouTok's pleasure. If you want to make some contributions to DouTok, we suggest open another issue which used to tell everyone what you want to do and assign it to yourself. In the way, we can avoid different people doing the same job.

The following is something what we want to do. Absolutely, anything that does not appear below is acceptable.

Run & Build & Deploy

• Explore how to run applications easily. Now we have many modules, we only can run them by using go run ./applications/xxx/. We may use a better way to do these. See more on: use make to startup DouTok services #112

CI/CD

• Add golangci-lint to lint code by using github actions
• Run go test when open a PR
• Add a flow to obtain unit test coverage

Code Layout

Now the code of DouTok still not elegant enough. Code layout is a big problem. There many places in this repo is not OOP (although golang is not a 100% OOP language). We suggest that we can improve the code layout of this repo. applications/commentDomain is an example.

Some package may need refactor:

• applications/feed
• applications/message
• applications/messageDomain
• applications/publish
• applications/relationDomain @xwxb

Unit Test

Unfortunately, DouTok is poor on unit test. So any contributions for any package are welcome.

[xwxb]

I'd like to have a try at refactoring package relationDomain.

[TremblingV5]

I'd like to have a try at refactoring package relationDomain.

Thank you!

I think you may refer to userDomain or commentDomain. Of course, if there are better suggestions, you can comment or write code directly

[xwxb]

I'd like to have a try at refactoring package relationDomain.

Thank you!

I think you may refer to userDomain or commentDomain. Of course, if there are better suggestions, you can comment or write code directly

我其实不是很熟悉 DDD，目前大致重构了一部分（已经push到我自己的fork里了）。
这也是我第一次贡献我不太清楚，目前检查只通过了自己本地编译成功，golangcli-lint，和大概通过了简易的单元测试。
请教一下我现在是否可以直接先提个 PR（想确定现在这一步没问题再往下写），还是还应该再做点别的事情？

[TremblingV5]

I'd like to have a try at refactoring package relationDomain.

Thank you!

I think you may refer to userDomain or commentDomain. Of course, if there are better suggestions, you can comment or write code directly

我其实不是很熟悉 DDD，目前大致重构了一部分（已经push到我自己的fork里了）。
这也是我第一次贡献我不太清楚，目前检查只通过了自己本地编译成功，golangcli-lint，和大概通过了简易的单元测试。
请教一下我现在是否可以直接先提个 PR（想确定现在这一步没问题再往下写），还是还应该再做点别的事情？

首先，我认为DDD这个东西不必太过于在意它，现有的模块划分更多的只是为了避免循环调用，到底是不是教科书般的DDD或是DDD的最佳实践我觉得其实不是那么重要，能够比较舒服的让项目得到发展就可以了。

如果现在的工作告一段落，可以考虑先提一个PR，在PR中描述下做了什么。

[xwxb]

I'd like to have a try at refactoring package relationDomain.

Thank you!
I think you may refer to userDomain or commentDomain. Of course, if there are better suggestions, you can comment or write code directly

我其实不是很熟悉 DDD，目前大致重构了一部分（已经push到我自己的fork里了）。
这也是我第一次贡献我不太清楚，目前检查只通过了自己本地编译成功，golangcli-lint，和大概通过了简易的单元测试。
请教一下我现在是否可以直接先提个 PR（想确定现在这一步没问题再往下写），还是还应该再做点别的事情？

首先，我认为DDD这个东西不必太过于在意它，现有的模块划分更多的只是为了避免循环调用，到底是不是教科书般的DDD或是DDD的最佳实践我觉得其实不是那么重要，能够比较舒服的让项目得到发展就可以了。

如果现在的工作告一段落，可以考虑先提一个PR，在PR中描述下做了什么。

了解了。已提 PR，有空的时候辛苦帮忙 Code Review 一下