application brief architecture

                            users
                              |
--------------------------------------------------------------------------------------------------------app
                        gateway.route   (route link all your routes together.)
LAYER GATEWAY           /            \
            gateway.sub_route1   gateway.sub_route2 ...
                       \              /
                        \            /
LAYER SERVICE               service      (service provides business logic by combining domains.)
                        /      |       \
                       /       |        \
LAYER DOMAIN        domain1  domain2   domain3 ...   (According to `DDD`, domains are isolated from each other. No calling relationship between domains)
                        \      |        /
                         \     |       /
LAYER DAO                     dao
                               |
                        infrastructure

层次越高，越和用户/业务逻辑相关，变化的可能性越大；
层次越低，越和用户/业务逻辑无关，变化的可能性越小

application project backbone

我们把上面的软件系统架构落实成 用于组织项目代码的 手脚架上

以go为例

├── app_root_dir                          // your project root
    ├── main.go                           // application entry
    │
    ├── config.go                         // provide conf
    │
    ├── gateway                           // pkg `gateway` provide user interface(api)
    |    ├── route.go                     // route links all your routes together
    |    ├── sub_route1.go
    |    ├── ... .go
    │    └── sub_routeN.go
    │
    ├── service                           // pkg `service` provides business logic
    |    ├── business1.go                  
    |    ├── business2.go
    |    ├── ... .go
    │    └── businessN.go
    │
    ├── domain    
    |    ├── domain1                      // each domain provides domain-cohesive functionality
    |    |   ├── a.go
    |    |   └── b.go
    |    └── domain2                 
    |        ├── c.go
    |        └── d.go
    |
    ├── dao                               // pkg `dao` separates the data persistence logic, provides data access and persistence service
    |   ├── interface.go                  // define dao interfaces
    |   └── impl.go                       // implement the defined interfaces. Typically, use model and specific database infrastructure to implement dao interfaces
    |
    ├── model                             // pkg `model` provides main data structs passed between different layers of the app
    |   ├── m1.go                  
    |   └── m2.go           
    |
    └── util

some notes:

• dao design pattern: https://www.digitalocean.com/community/tutorials/dao-design-pattern

• model vs dao

DAO classes talk to both your persistence system (generally a database) and your controller, and move instances of your model classes between them.

Model classes are a representation of the real world stuff that you're working with (patients, doctors and appointments for a hospital management app, for example, or clients, accounts and so on for a bank app). Ideally, your model classes shouldn't even know that there's a DAO.

DAO is a CRUD oriented data service (read/create/update/delete data) while model are objects representing data.