1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
# Code organization
This document explains the rationale for the server's module structure and overall code layout, rather than the layout. If you're looking for a map, look in `src/lib.rs`.
Trust your gut, and reorganize to meet new needs. We've already revised this scheme several times as the code base has grown, and there's no reason we can't do so again.
## Topic modules
High-level concerns are grouped into topical modules. These include `crate::conversation`, `crate::events`, `crate::login`, and others. Those modules generally contain their own app types, their own repo types, their own extractors, and any other supporting code they need. They may also provide an interface to other modules in the program.
Most topic modules contain one or more of:
- An `app` module exposing the primary operations on the topic domain,
- An `id` module defining any domain-specific identifier types,
- A `handlers` module exposing Axum handler functions,
- A `repo` module exposing database access types,
- A `history` module exposing history types,
- A `snapshot` module exposing state types, or
- An `events` module exposing domain-specific event types.
Not every topic modules hits every common convention, and some topic modules vary from the conventions to meet their specific design needs.
## Cross-cutting modules
However, some cross-cutting parts of the system have been pulled out into top-level modules of their own. These include `crate::routes`, `crate::app`, `crate::clock`, and others. Reasons for doing this include having multiple equally-valid modules the code could have been put in, keeping the use of namespaces legible, and others.
|
