[healsjnr1]

I don't know that I completely follow on this comment, in particular how code reuse comes into it.

I think the biggest thing is about deciding whether you have one or many.

There are a lot of cases where having many doesn't just mean there is a list to show.

In a lot of cases, having many means you now need to choose "the right one" to show/edit/action whatever.

This brings up all sorts of complications beyond "just return a list instead of a single item".

Even if you don't end up building it out, I think it always a good thought experiment during the design phase to think about how things would behave if there where multiple of key resources, rather than just one.

Would it have implications elsewhere? Are there low cost alterations to the design that can be made now that make space / allow for this key resources to be a list later on? How hard would it these be to do later?

I'm many cases the conclusion might be it isn't worth it and that's the right choice (yagni applied judiciously), but every now and again this might highlight a valuable early stage change that would have cost a lot to make later on.

[code_runner]

I took this as “if you need more than one, plan for storing ANYTHING greater 1 or greater”

Meaning that if I need to store specifically 2 addresses per user, don’t force it at the data layer… just make it an easy to swap validation and no literal limits elsewhere

[mattclarkdotnet]

For display/view purposes, yes you need to decide what the likely option is. For model/type purposes, the decision to have a 1:1 relationship should be made only with great care, as the OP shows with the example of addresses.