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
|
||||
|
||||
Reference in New Issue
Block a user