dev: chore, added README
This commit is contained in:
+38
-1
@@ -1 +1,38 @@
|
||||
# APP DESIGN CONVENTION
|
||||
# APP DESIGN CONVENTION
|
||||
|
||||
## Implementing Clean Architecture (later called CA) in the layout
|
||||
1. The CA can be implemented simply by using directory structures to represent the layers
|
||||
2. The CA directories will be inside the "internal" directory due to its nature that the codes inside it is basically intended for the business model
|
||||
3. The CA will have the following directories:
|
||||
1. `domain`, with sub-directories:
|
||||
1. `references`, for common type, const, variabel
|
||||
2. `main-entities`, for the main models
|
||||
3. `bpjs-entities`, for the bpjs models. Good to know that this was intitially added but later being stripped for its busines model. This still can be unstriped later.
|
||||
4. `satusehat-entities`, for the satusehat models
|
||||
5. ...
|
||||
2. `application`, with sub-directories:
|
||||
1. `helpers`, some general helper
|
||||
2. `main-cases`, for the main flows
|
||||
3. `bpjs-cases`, the expansion flows for the bpjs
|
||||
4. `satusehat-cases`, the expansion flows for the satusehat
|
||||
5. ...
|
||||
3. `interface`, with sub-directories:
|
||||
1. `main-handler`
|
||||
2. `jkn-handler`
|
||||
3. `main-migration`
|
||||
4. `satusehat-migration`
|
||||
5. ....
|
||||
4. `infra` has no specific-grouping directories, instead, it will have several directories related to each purpose directly like:
|
||||
1. `jkn`, to connect with jkn service
|
||||
2. `satusehat`, to connect with satusehat service and satusehat local db
|
||||
3. `minio`, to connect with minio service
|
||||
4. ....
|
||||
4. Several used libraries might have their own infra-purposed feature which will be outside the infra directory.
|
||||
|
||||
## ERD to Entity
|
||||
All of the MainERD, SSERD, and ExtRefERD will be the entities in the implementation. There will be at least 2 databases: main and satusehat. bpjs is still in the consideration.
|
||||
|
||||
## Middlewared Use-Case
|
||||
1. To make the applcation have more dynamic flows, each use-case can implement the midlewared model
|
||||
2. The idea is to make its basic process of use case clean, adding more flows can be done outside it
|
||||
3. This method relatively makes the code easier to maintain in the future
|
||||
|
||||
@@ -1,2 +1,55 @@
|
||||
# SIMRS-VX
|
||||
# RSSA SIMRS-VX BACKEND
|
||||
Or in english Hospital Information Management System (HIMS), is a system that
|
||||
manages the information of the hospitals and the patients.
|
||||
|
||||
## Stacks
|
||||
- Language : Golang<br />
|
||||
Link: https://go.dev
|
||||
- Framework : No Framework<br />
|
||||
Why? Go (Golang) applications often do not require full-fledged frameworks
|
||||
due to several key aspects of the language and its ecosystem:
|
||||
- Comprehensive Standard Library: Go's standard library is exceptionally
|
||||
robust and provides much of the functionality that would typically be found
|
||||
in frameworks in other languages.
|
||||
- Simplicity and Explicit Design: Go emphasizes simplicity and clarity.
|
||||
Frameworks often introduce a degree of "magic" or hidden complexity
|
||||
through inversion of control, where the framework dictates the
|
||||
application's flow
|
||||
- Modular Libraries: Instead of a single, all-encompassing framework, the Go
|
||||
community favors small, modular libraries that perform specific tasks well.
|
||||
- Performance and Efficiency: Go is designed for performance and efficiency.
|
||||
Frameworks can sometimes introduce performance overhead due to their layers
|
||||
of abstraction.
|
||||
|
||||
So? No framewok is the best framework.
|
||||
- Database : PostgreSQL<br />
|
||||
Link: https://www.postgresql.org
|
||||
- Cache : Redis<br />
|
||||
Link: https://redis.io
|
||||
- File Server : Minio<br />
|
||||
Link: https://www.min.io
|
||||
|
||||
## Libraries
|
||||
- Routing Helper: Apem<br />
|
||||
Link: https://github.com/karincake/apem
|
||||
- ORM: GORM<br />
|
||||
Link: https://gorm.io
|
||||
- Database Migration: Atlas<br />
|
||||
Link: https://atlasgo.io/guides/orms/gorm/program
|
||||
|
||||
## Others
|
||||
- Project Layout: Golang Standards Project Layout<br />
|
||||
Link: https://github.com/golang-standards/project-layout
|
||||
- Architecture: Clean Architecture<br />
|
||||
Link: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
|
||||
|
||||
## Commands
|
||||
- Main api:
|
||||
- go to the ./cmd/main-api
|
||||
- run `go run .` to run in debug mode
|
||||
- run `go build` to build the binary
|
||||
- Main migration:
|
||||
- go to the ./cmd/main-migration
|
||||
- run `go run .` to run in debug mode
|
||||
- run `go build` to build the binary
|
||||
|
||||
|
||||
Reference in New Issue
Block a user