Again, they are talking about technologies not methodologies. People forget DV 2.x is not just a way to model data but architecture and methodology too. All of it still applies in the modern data landscape. Dan's new DV 2.1 course now includes discussions about data lakes and PSAs and virtualization. In the end you still have to a plan and approach and at a minimum you need the business ontology and taxonomy to properly build a virtualization layer that makes sense to the business. You can use DV for all of that! A logical DV model can certainly be used to build the model inside a virtualization tool.

Check Snowflake.com/blog for lake house articles. Also their resources page for white papers and presos. I know some of the Field CTOs and SE have done talks and posts over the last few years. Check LinkedIn postings from Kevin Bair at Snowflake as he works exclusively on data cloud architecture these days.

Sadly too many people do not understand the difference between an architecture (e.g., Medallion) and a methodology like Data Vault 2.x.

Check out https://datameshlearning.com/ . They also have a Slack channel with lots of activity on it.

Usually, I prefer to put address attributes in a Sat. However, I did have this same case in a Healthcare warehouse because there were multiple specialty clinics housed at the same address. The BK was very similar to the example and it really was the best way to identify a building owned by the agency, and was how the business thought of it. We used the full set of attributes for the BK and hashed then according to the DV 2 best practices. I would never recommend using a surrogate key for the address BK (or any Hub actually) as that really will not work unless you have only one source system for addresses over time. Very unlikely, hence the use of true BK attributes to future proof your design. I do like the idea of using a JSON document with all the attributes as the BK and then hash that for the Hub PK. I did not have that as an option at the time. With the VARIANT data type in Snowflake, that is now a valid option to consider. However, as Michael points out, if the keys within the JSON get reordered, you might end up loading technical duplicates because they will hash to different values. In that case you may need a Same as Link to align them in your Business Vault.