[dreamer7]

That is definitely easier to work with but may not solve all problems. In the parent example, they mention Country and CountryCode. What if one team decided that they needed codes and the other needs the full name?

There has to be company-level standards to ensure consistency. And it is so hard to enforce standards unless a culture of revisiting and generalising things is created while growing from a small team.

[HighlandSpring]

It is not hard to standardise an Address type across a company (they are a shopping product after all)

Or better yet, define which types are required and which are optional so at least naming is consistent

[km3r]

As someone who has worked on addresses for a large corperate system, addresses can get very complicated. International localization, formatting, different usages (shipping, billing, mailing, taxes), multiple addresses per user, and security all start to add up, with many different part of the application having different requirements. Even as the team that owned addresses we debated whether new use cases should spin up their own implemention. Though it's pretty interesting seeing how different countries do addresses differently.for example, users in South Korea expect to be able to search for addresses and just enter an apartment number. Some countries went to near 9 lines of info.

[stickfigure]

Shopify does not have this problem. There is no excuse for these addresses to be different. Case in point - look at Order vs FulfillmentOrder. The destination is a simple copy! Even worse, FO is missing the country code and province code, including only the (useless for shipping) full text. It's daft.

A typed language helps because you would have to make an explicit decision to use a non-standard Address. And the 2 vs 3 digit country code conflict is an issue with "stringly typed" code; don't do that, make a CountryCode type instead and constrain it.