feat: add the core project design

README.md

@@ -1,5 +1,20 @@
 # howmuch
 
+<!--toc:start-->
+- [howmuch](#howmuch)
+  - [Project Diary](#project-diary)
+    - [2024/09/30](#20240930)
+    - [2024/10/01](#20241001)
+      - [Config](#config)
+      - [Business logic](#business-logic)
+      - [Startup framework](#startup-framework)
+    - [2024/10/02](#20241002)
+      - [Logging](#logging)
+      - [Version](#version)
+    - [2024/10/03](#20241003)
+    - [2024/10/04](#20241004)
+<!--toc:end-->
+
 A tricount like expense-sharing system written in Go
 
 ---
@@ -99,7 +114,7 @@ consumer queue, etc.
 #### Startup framework
 
 When business logic becomes complicated, we cannot spread them into a simple
-`main` function. We need something to handle all thoses task, sync or async.
+`main` function. We need something to handle all those task, sync or async.
 That is why we use `cobra`.
 
 So for this project, we will use the combination of `pflag`, `viper` and
@@ -134,3 +149,49 @@ A more comprehensible error code design :
 - error message.
 
 The service error code helps to identify the problem more precisely.
+
+### 2024/10/04
+
+Application architecture design follows [Clean Architecture](https://manakuro.medium.com/clean-architecture-with-go-bce409427d31)
+that has several layers:
+
+- Entities: the models of the product
+- Use cases: the core business rule
+- Interface Adapters: convert data-in to entities and convert data-out to
+output ports.
+- Frameworks and drivers: Web server, DB.
+
+Based on this logic, we create the following directories:
+
+- `model`: entities
+- `infra`: Provides the necessary functions to setup the infrastructure,
+especially the DB (output-port), but also the router (input-port). Once
+setup, we don't touch them anymore.
+- `registry`: Provides a register function for the main to register a service.
+It takes the pass to the output-port (ex.DBs) and gives back a pass
+(controller) to the input-port
+- `adapter`: Controllers are one of the adapters, when they are called,
+they parse the user input and parse them into models and run the usecase
+rules. Then they send back the response(input-port). For the output-port
+part, the `repo` is the implementation of interfaces defined in `usecase/repo`.
+- `usecase`: with the input of adapter, do what have to be done, and answer
+with the result. In the meantime, we may have to store things into DBs.
+Here we use the Repository model to decouple the implementation of the repo
+with the interface. Thus in `usecase/repo` we only define interfaces.
+
+Then it comes the real design for the app.
+
+Following the Agile method, I don't try to define the entire project at the
+beginning but step by step, starting at the user part.
+
+```go
+type User struct {
+	CreatedAt   time.Time
+	UpdatedAt   time.Time
+	FirstName   string
+	LastName    string
+	Email       string
+	Password    string
+	ID          int
+}
+```