Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce Architecture Decision Records #13

Merged
merged 22 commits into from
Jun 9, 2021
Merged

Conversation

ghost
Copy link

@ghost ghost commented Jun 8, 2021

Architecture Decision Records, or ADRs, are a form of lightweight documentation of the architecture, or more generally technical, decisions made or revoked during the development of a system.

@ghost ghost requested review from ch1bo and KtorZ June 8, 2021 10:27
@ch1bo
Copy link
Member

ch1bo commented Jun 8, 2021

A README.md in docs/adr/ would be helpful and can serve as an index (what you started in the Wiki / Technical Architecture)

docs/README.md Outdated
@@ -0,0 +1,3 @@
# Documentation

* Technical [Architecture](architecture.md): Main entry point for technical details about Hydra node implementation
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This indirection is not required IMO, I'd just put the technical architecture document in place here until we have other docs.

Please refer to each component's internal documentation for details.

* The [HydraNode](../hydra-node/src/Hydra/Node.hs) is a handle to all other components' handles
* This handle is used by the main loop to `processNextEvent` and `processEffect`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Anything referring to actual identifiers should be in the module haddock IMO. But this is out of scope for this PR and I gladly help in moving these things and make it coherent :)

## Decision

* We will use _Architecture Decision Records_, as described by Michael Nygard in this article: http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions
* We will follow the convention of storing those ADRs as Markdown formatted documents stored under `docs/adr` directory, as exemplified in Nat Pryce's [adr-tools](https://raw.githubusercontent.com/npryce/adr-tools). This does not imply we will be using `adr-tools` itself.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Broken link to adr-tools


## Consequences

See Michael Nygard's article, linked above.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't it be helpful to extract the bits we deem as important here? or do we expect anyone to read the article anyway?

docs/adr/README.md Outdated Show resolved Hide resolved
docs/adr/0002-reactive-core.md Outdated Show resolved Hide resolved
docs/adr/0003-asynchronous-duplex-api.md Outdated Show resolved Hide resolved
docs/adr/0003-asynchronous-duplex-api.md Outdated Show resolved Hide resolved
docs/adr/0004-use-handle-to-model-effects.md Outdated Show resolved Hide resolved
docs/adr/0004-use-handle-to-model-effects.md Outdated Show resolved Hide resolved
@ch1bo ch1bo self-requested a review June 9, 2021 10:19
@ch1bo ch1bo merged commit 3158e99 into master Jun 9, 2021
@ch1bo ch1bo deleted the abailly-iohk/introduce-adrs branch June 9, 2021 10:20
Copy link
Collaborator

@KtorZ KtorZ left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants