Informações de endereço devem ficar juntas ou separadas do modelo a qual elas se referem?

Não tem um errado nessa história, são 2 modos de se fazer a mesma coisa. Tem que ver o melhor pra sua situação.

Eu particularmente iria também preferir separar o endereço da loja. Assim, se outra parte do sistema usar os endereços, as cidades e os estados já tem tudo ali pronto.

Por se tratar de endereço de uma “Loja” eu também ficaria com a segunda opção. Você não vai reaproveitar essa tabela/modelo de endereços, vai por mim. Se tiver que fazer isso é melhor usar um modelo separado com dados do correio ou desse tipo. É melhor colocar na tabela da loja para evitar vários acessos no banco de dados e até a criação de classes a mais para tratar uma coisa que será sempre da mesma maneira.
Se fosse o endereço do cliente por exemplo ai faria mais sentido usar a tal tabela/ modelo dos correios. Não consigo ver onde você aproveitaria esses dados do endereço se separa-los das lojas. De qualquer forma para te ajudar basta fazer uma pergunta fácil fácil:

O Endereço pode existir no sistema sem que haja uma loja associada a ele?
Sim - faça o modelo separado e quando for cadastrar uma loja obrigue o usuário a escolher/pesquisar um endereço existente.
Não - faça junto com a loja.

Lembre-se que uma loja é única e possui apenas 1 endereço, mesmo que seja na mesma rua ela tera um número diferente.

mvargens:

Por se tratar de endereço de uma “Loja” eu também ficaria com a segunda opção. Você não vai reaproveitar essa tabela/modelo de endereços, vai por mim. Se tiver que fazer isso é melhor usar um modelo separado com dados do correio ou desse tipo. É melhor colocar na tabela da loja para evitar vários acessos no banco de dados e até a criação de classes a mais para tratar uma coisa que será sempre da mesma maneira.
Se fosse o endereço do cliente por exemplo ai faria mais sentido usar a tal tabela/ modelo dos correios. Não consigo ver onde você aproveitaria esses dados do endereço se separa-los das lojas. De qualquer forma para te ajudar basta fazer uma pergunta fácil fácil:

O Endereço pode existir no sistema sem que haja uma loja associada a ele?
Sim - faça o modelo separado e quando for cadastrar uma loja obrigue o usuário a escolher/pesquisar um endereço existente.
Não - faça junto com a loja.

Lembre-se que uma loja é única e possui apenas 1 endereço, mesmo que seja na mesma rua ela tera um número diferente.

Outro motivo pelo qual eu quero colocar em modelos/tabelas separadas é pra poder criar um script que carregue todas os estados e cidades do Brasil, além de relacionar cada cidade com seu respectivo estado. Dessa forma, a seleção de ambos se dá através de um combo box, onde primeiro seleciona-se o estado, e em seguida o combo box das cidades é preenchido. Tendo isto em vista, fica ainda mais difícil e, na minha opinião, estranho, usar a tabela de lojas pra inserir os estados e cidades do Brasil pra popular os combo box mencionados.

Realmente fica estranho usar a tabela de loja para carregar 1 combo que poderia até ser fixo. Mais eu ainda acho mais estranho criar um modelo de dados complexo (vide o modelo dos correios) por causa de um combo fixo.
Acho que sua intenção é boa, mas um modelo de endereços realmente funcional é bem complexo. Lembre-se que vai ter que quebrar e associar por Cep, endereço, complemento, numero, bairro, cidade, estado.
Deixar o usuário digitar o endereço é a pior coisa que você pode fazer em um modelo assim. Ou você tem tudo pronto ou é melhor nem fazer. Por isso recomendei o esquema dos correios.
Você deve ter um prazo para entregar isso ai. Pense nas classes e testes que terá que fazer para manter esse modelo. Se vai fazer meia boca é melhor fazer do jeito que seu amigo propôs.
Agora se está convencido que vai reaproveitar todo o modelo de endereço em outra parte do sistema não faz sentido não fazer separado.

mvargens:

Realmente fica estranho usar a tabela de loja para carregar 1 combo que poderia até ser fixo. Mais eu ainda acho mais estranho criar um modelo de dados complexo (vide o modelo dos correios) por causa de um combo fixo.
Acho que sua intenção é boa, mas um modelo de endereços realmente funcional é bem complexo. Lembre-se que vai ter que quebrar e associar por Cep, endereço, complemento, numero, bairro, cidade, estado.
Deixar o usuário digitar o endereço é a pior coisa que você pode fazer em um modelo assim. Ou você tem tudo pronto ou é melhor nem fazer. Por isso recomendei o esquema dos correios.
Você deve ter um prazo para entregar isso ai. Pense nas classes e testes que terá que fazer para manter esse modelo. Se vai fazer meia boca é melhor fazer do jeito que seu amigo propôs.
Agora se está convencido que vai reaproveitar todo o modelo de endereço em outra parte do sistema não faz sentido não fazer separado.

Ótimo, você conhece a solução e sabe quanto tempo leva. O problema é apenas saber se vale o esforço sim ou não. Eu acho que não vale, mas sem duvida nenhuma é melhor fazer assim até porque quem vai cadastrar a loja só precisa digitar o cep, número e complemento. Mas lembre-se, você tem prazo para entregar isso funcionando do jeito que pediram.

elomarns:

…
Já este meu amigo, sugeriu colocar o endereço da loja no modelo/tabela da loja, ou seja, tudo ficaria concentrado no mesmo modelo/tabela. Eu achei essa opção ruim, já que ao meu ver é anêmica, uma vez que a o model da loja estaria representando muitos conceitos simultaneamente, resultando em uma classe com diversas métodos e validações não muito relacionados, além de testes bem gordos. Ao argumentar contra a idéia, ele disse que essa é a melhor opção por ser mais simples e performática. De fato é a mais simples, ou melhor, é a mais simplória. Já em relação a performance ela realmente é ligeiramente melhor, uma vez que evita consultas a outras tabelas, o que é amenizado pelo lazy loading no caso da minha sugestão.

Enfim, eu acredito que estou certo quando ao meu ponto de vista. Acho que é incabível colocar a informação do endereço no mesmo model/tabela que as informações mais gerais da loja.
…

Independente de como você fará isso no seu banco de dados, isso não precisa refletir o domínio da sua aplicação. As tuas classes não precisam se espelhar nas tabelas. Você pode ter uma tabela Loja com campos de Endereco, porém no sistema você tem uma classe Loja que possui um Endereco. Aliás, você nem deve armazenar essas ‘validações’ de Endereco na classe que representa a tua Loja.

Se você tiver, leia no DDD a respeito de Value Objects e Entities. Me parece que a sua dúvida pode ser em relação a isso (como você define um endereço, já que ele pode ser visto tanto como um Value Object como uma Entity).

Falou.