github.com/simpleiot/simpleiot@v0.18.3/docs/adr/README.md (about) 1 # Architecture Decision Records 2 3 This directory is used to capture Simple IoT architecture and design decisions. 4 5 For background on ADRs see 6 [Documenting Architecture](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions) 7 Decisions by Michael Nygard. Also see 8 [an example](https://github.com/nats-io/nats-architecture-and-design) of them 9 being used in the NATS project. The 10 [Go proposal process](https://github.com/golang/proposal#readme) is also a good 11 reference. 12 13 ## Process 14 15 When thinking about architectural changes, we should 16 [lead with documentation](https://handbook.tmpdir.org/documentation/lead-with-documentation/). 17 This means we should start a branch, draft a ADR, and then open a PR. An 18 associated issue may also be created. 19 20 ADRs should used primarily when a number of approaches need to be considered, 21 thought through, and we need a record of how and why the decision was made. If 22 the task is a fairly straightforward implementation, write documentation in the 23 existing User and Reference Guide sections. 24 25 When an ADR is accepted and implemented, a summary should typically be added to 26 the [Reference Guide](../../README.md) documentation. 27 28 See [template.md](template.md) for a template to get started. 29 30 ## ADRs 31 32 | Index | Description | 33 | ----------------------------------------------- | ------------------------------------------- | 34 | [ADR-1](1-consider-changing-point-data-type.md) | Consider changing/expanding point data type | 35 | [ADR-2](2-authz.md) | Authorization considerations. | 36 | [ADR-3](3-node-lifecycle.md) | Node lifecycle | 37 | [ADR-4](4-time.md) | Notes on storing and transfering time | 38 | [ADR-5](5-time-validation.md) | How do we ensure we have valid time | 39 | [ADR-6](6-time-storage-in-rule-schedule.md) | How to handle time in rule schedules | 40 | [ADR-7](7-jetstream-store.md) | Use NATS Jetstream for the SIOT store |