dev: chore, added README
This commit is contained in:
No files matched your search
@@ -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