This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-04
Channels
- # architecture (13)
- # bangalore-clj (1)
- # beginners (174)
- # boot (25)
- # cider (65)
- # cljs-dev (10)
- # cljsjs (4)
- # cljsrn (3)
- # clojure (169)
- # clojure-berlin (27)
- # clojure-brasil (32)
- # clojure-greece (3)
- # clojure-russia (31)
- # clojure-sg (4)
- # clojure-spec (6)
- # clojure-uk (74)
- # clojurescript (186)
- # code-reviews (5)
- # css (12)
- # cursive (17)
- # datascript (1)
- # datomic (45)
- # dirac (33)
- # funcool (42)
- # hoplon (25)
- # jobs (6)
- # jobs-discuss (114)
- # lambdaisland (6)
- # leiningen (1)
- # luminus (24)
- # off-topic (86)
- # om (13)
- # om-next (14)
- # onyx (75)
- # perun (2)
- # protorepl (19)
- # re-frame (2)
- # reagent (17)
- # ring-swagger (2)
- # rum (1)
- # slack-help (2)
- # specter (31)
- # test-check (5)
- # timbre (1)
- # untangled (34)
- # vim (8)
@mtnygard I saw your blog post on ADRs from 2011 (http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions), is there anything that you would add to that 5 years later?
@gdeer81 I think it holds up pretty well. I'd add the Arachne project as a good open-source use of ADRs so there are some nice examples. Maybe also say that "alternatives considered" typically below in the context. If you considered a solution, but rejected it there must be some evidence or reasons & that's part of context.
Really one of the hardest parts to write is the context. That's because you have to make a bunch of implicit knowledge explicit so people can understand your decision in the future.
we've been so hung up on trying to document things in confluence and sharepoint that we never thought to just use git
@mtnygard you've worked with ATG before, so you know the butterfly effect it can have when you make a decision in a framework that complex
the problem with git (at least for us) is that architecture decisions usually involve multiple repositories. is there any way around that, other than creating a repo just for architecture decisions ?
@lmergen yeah I was thinking about that same thing with our Tibco integrations that are just little machines connected together but each one is kept in a separate repo so modifying how pricing changes flow from the source system, to all the stores, and the website requires touching like 5 or 6 repos. I guess we could reference ADRs in other repos to show the relationship. Creating a separate repo just for documentation seems kind of awkward