Architecture Decision Records (ADR) as a LOG that answers "WHY?"

  Рет қаралды 17,648

CodeOpinion

CodeOpinion

Күн бұрын

Пікірлер: 24
@CodeOpinion
@CodeOpinion 3 жыл бұрын
Here are some links mentioned in the video: ADR Tools: github.com/npryce/adr-tools Templates: github.com/joelparkerhenderson/architecture-decision-record
@carlosalbertohernandezmogu7684
@carlosalbertohernandezmogu7684 3 жыл бұрын
So simple, so powerful
@cupofkoa
@cupofkoa 3 жыл бұрын
I've been asking a lot of 'why' questions recently, especially around areas of infrastructure where it seems to be overkill. If I knew why it was designed in a more complicated way then I'd feel better. Some architects talk about using decision trees, and been meaning to read the book from Mark Richards about ADRs. Looks like this video was uploaded at a good time.
@CodeOpinion
@CodeOpinion 3 жыл бұрын
Hopefully it helps.
@MichielCornille
@MichielCornille 3 жыл бұрын
Does it make sense to use these same templates for "Adaptation decisions" made in a retrospective meeting?
@CodeOpinion
@CodeOpinion 3 жыл бұрын
Not entirely sure what you mean by "Adaptation decisions" but from what I'm assuming, yes I can see any type of ADR being useful to review so everyone knows it's occurred. Especially if you're going through an approval process.
@MichielCornille
@MichielCornille 3 жыл бұрын
@@CodeOpinion I meant when you Inspect & Adapt :)
@sathyajithps013
@sathyajithps013 3 жыл бұрын
I had this problem. When I looked back at the code I wrote months ago, I'm like : "What!!". So I created a text file in each directory that hold some logic or a feature (say, the repository, or in the aggregate root dir etc..) and described what the files did and why it was there.Its not ADR per se but it was a little helpful to me later. I did not think of documenting the context it was written under. Its a good idea to include the context. I also was replacing it instead of appending it. When i think about it, it is better to append than replace. One doubt I have is, should there be just one ADR file for a project and document everything there or is it just preference or as per the project requirements ? I think for a new change, we can append a new ADR file. What I meant was, should there be different ADRs for repo, domain logic etc..
@CodeOpinion
@CodeOpinion 3 жыл бұрын
I'd have multiple ADR files per repo. You can also in code comments reference the ADR #. But again, you could have one single file that you keep appending to as well. This isn't a terrible idea because you probably want to optimize for reading not writing.
@sathyajithps013
@sathyajithps013 3 жыл бұрын
@@CodeOpinion Mmh yap. I'll try and keep a single ADR on my ongoing project and see how that goes. Makes sense to just do the one ADR per repo. Thanks for the suggestion. I'll let you know the results after I forget about the project and come back to it months later when the client finally decides on which color the interface should be.lol.
@tolela22
@tolela22 2 жыл бұрын
Nice video! Very clear and complete.
@asMdl
@asMdl Жыл бұрын
Will the future person that has to deal with an unknown code will find it if it is not in the repo? Where would you guys store this docs? I would like to know all your opinions. It might imply a change in a service but it is motivated by the context… It can affect infrastructure and as a consequence maybe it also makes you refactor one or many services. Store it In the service repo? In an exclusive doc repo? In your IaC repo!!?
@thedacian123
@thedacian123 2 жыл бұрын
So message librraries are abstractions on top of message broker ,as on orm abstract dbms engine?
@CodeOpinion
@CodeOpinion 2 жыл бұрын
Correct. Beyond that they provide implementations for various patterns that are common with event driven architecture and messaging. If you were just use an sdk of a broker, you'd likely end up having to implement all of them yourself. Claim checks, encryption, outbox, retries, the list goes on.
@raghuveerdendukuri1762
@raghuveerdendukuri1762 3 жыл бұрын
Very good suggestion, while I used to briefly note changes in the changeling for opensource libraries, your suggestion helps to focus in architect perspective and to documents decisions
@CodeOpinion
@CodeOpinion 3 жыл бұрын
Ad mentioned in the video I think the context is so important. Which usually needs a bit more elaboration on what are the driving forces and options.
@raghuveerdendukuri1762
@raghuveerdendukuri1762 3 жыл бұрын
@@CodeOpinion fully agree
@YoMeroChaman
@YoMeroChaman 2 жыл бұрын
I liked it! I found this easy to maintain and easy to elaborate! But this is for the long-term future. So why did I write the code in that way?
@interestingcoding4698
@interestingcoding4698 2 жыл бұрын
Nice video, thank you for sharing this methodoly. Question: What if a made a desicion and then I wanna change that desicion, should I create a new log or just modify the existing one? Greettings from Argentina :)
@CodeOpinion
@CodeOpinion 2 жыл бұрын
New ADR that references the one it's adjusting/replacing.
@rajneeshtiwari6345
@rajneeshtiwari6345 3 жыл бұрын
Good explanation ❤️ it
@CodeOpinion
@CodeOpinion 3 жыл бұрын
Thank you 🙂
@ddddddddd345
@ddddddddd345 2 жыл бұрын
There's bunch of similar tooling for all sorts of purposes (e.g. `vitiral/artifact`), and it all seems nice in theory, but it doesn't work in practice. Sure, sometimes one asks "why?" and would be nice to get a complete and comprehensive answer, but how often does it *really* happen? Is it worth continuous overhead of maintaining yet another thing, making sure all developers know about it and consistently update it so on? And can it even be relied on to be there in the first place? I mean - maybe, sometimes, in some domains, etc. it could work, but from my PoV rapid development and time to market often steamroll over even way more basic good practices, so trying to add even more aspirational one is just not going to work. There is already a git log, and in-code documentation, and it seems more practical and realistic to focus on driving teams to write more and higher quality commit messages and comments, and improve `git log/blame`-fu (--ignore-rev yay!), etc. leveraging already existing facilities, than try to introduce another one, IMO.
@Krow-n3o
@Krow-n3o 2 жыл бұрын
You can enable non tech mates to read the ADR and try to colaborate, but they can't create a git and learn how to read comments...
Q&A: Messaging, CQRS & Event Sourcing!
14:37
CodeOpinion
Рет қаралды 10 М.
REST APIs for Microservices? Beware!
11:49
CodeOpinion
Рет қаралды 49 М.
Quando A Diferença De Altura É Muito Grande 😲😂
00:12
Mari Maria
Рет қаралды 45 МЛН
It works #beatbox #tiktok
00:34
BeatboxJCOP
Рет қаралды 41 МЛН
Sagas: Event Choreography & Orchestration (NServiceBus)
15:18
CodeOpinion
Рет қаралды 41 М.
Clean Architecture Example & Breakdown - Do I use it?
15:25
CodeOpinion
Рет қаралды 187 М.
Real 10x Programmers Are SLOW To Write Code
14:51
Thriving Technologist
Рет қаралды 68 М.
Message Driven Architecture to DECOUPLE a Monolith
12:33
CodeOpinion
Рет қаралды 13 М.
Event-Driven Architecture (EDA) vs Request/Response (RR)
12:00
Confluent
Рет қаралды 178 М.
Visualise, document and explore your software architecture -  Simon Brown
57:26
Workflow Orchestration for Building Resilient Software Systems
11:57
Microservices are Technical Debt
31:59
NeetCodeIO
Рет қаралды 696 М.
SATURN 2017 Talk: Architecture Decision Records in Action
28:08
Software Engineering Institute | Carnegie Mellon University
Рет қаралды 5 М.