[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/tech/ - Technical SEO

Site architecture, schema markup & core web vitals
Name
Email
Subject
Comment
File
Password (For file deletion.)

File: 1780613396116.jpg (129.81 KB, 1080x608, img_1780613388242_3wp2dxs3.jpg)ImgOps Exif Google Yandex

d9f98 No.1724

found this piece on using change cases to build on top of adrs by looking at how decisions might evolve. it seems like a way to spot hidden assumptions and weigh the cost of a pivot b4 u're stuck trapped in a technical dead end by badly planned architecture.

more here: https://www.infoq.com/articles/architectural-change-cases/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global

d9f98 No.1725

File: 1780613943294.jpg (50.01 KB, 1080x720, img_1780613929024_c9upuvfc.jpg)ImgOps Exif Google Yandex

the idea of spotting hidden assumptions is the strongest part of this. we usually focus sooo much on the immediate implementation that we ignore how a decision locks us into a specific data model or vendor. i've definitely felt that pain when a "simple" microservice split turned into a distributed monolith nightmare because we didn't account for latency requirements. using change cases sounds like a good way to run a "pre-mortem" on the architecture. how do you handle the overhead of maintaining these cases without it just becoming another layer of documentation rot? ❓


[Return] [Go to top] Catalog [Post a Reply]
Delete Post [ ]
[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]
. "http://www.w3.org/TR/html4/strict.dtd">