Dúvida sobre organização no Domínio

[Rodrigo Braga]

Senhores

Atualmente não trabalho em "projetos reais" com DDD, TDD, Scrum e
afins, porém tenho tentado estudar estes recursos.

E surgiu a seguinte dúvida, no meu projeto para fins de estudo eu
tenho umas três ou quatro classes apenas e fiz da seguinte forma,
dentro da minha camada de domínio (um projeto do tipo "class library")
eu criei um diretório chamado Entidades e naturalmente estou colocando
minhas entidades nela; porém se eu quiser usar Interfaces, classes
abstratas e etc.; existe alguma recomendação em segmentar por
diretórios também?

Algo como:

+ Entidades
+ Interfaces
+ Whatever...

No meu caso com poucas classes acho que seria indiferente, mas em
situações onde o número de classes aumenta um pouco isso pode
"amenizar" um pouco, seria assim mesmo ou é tudo junto mesmo?

--
Att.,
Rodrigo Braga

[Ricardo Simões]

Oi,

Como você está tentando utilizar DDD para modelar, basta saber se suas interfaces, classes abstratas, whatever, são de domínio, de infra, de interface, services, repositories, enfim... não há uma regra para a organização o melhor de tudo é entender bem os principios de modelagem orientada ao domínio e adicionar uma pitada de bom senso.

Espero que ajude.

[]'s

Ricardo Simões

2010/7/28 Rodrigo Braga <rbr...@gmail.com>

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

[Bruno D'Alessio]

A estruturação de diretórios diz respeito a organização.

Existe alguns documentos na WEB, bem interessantes sobre isso.

 

Eu pessoalmente gosto de dividir cada "tipo" em seu diretório.

 

Quanto a projetos do VS, você dividir seu dominio em mais de um projeto, eu recomendo para projetos "gigantes", onde talvez, você desacoplar,

a estrutura fisica gere beneficios.

 

Quando não, pode-se centralizar sem temor algum, seu dominio em apenas um projeto.

 

Desde que a divisão / hierarquia das camadas esteja evidente na sua solução e sua estrutura de diretórios facilite a localização dos arquivos,

fique a vontade.

 

Abs,

--
Bruno D'Alessio
Arquiteto de Software

[Denis Ferrari]

Não me parece legal a organização por tipos. O domínio é dividido em pacotes (de negócio), e todo tipo criado será armazenado em seu respectivo pacote, sem divisões que não dizem respeito ao domínio propriamente dito.

Abraços!

Denis Ferrari - "Faça pouco, faça sempre e faça direito"

Quer aprender TDD?
www.heroisdati.com/tdd-para-iniciantes-para-quem-quer-comecar-e-nao-sabe-como/

www.denisferrari.com
www.mindworks.com.br | www.msdev-es.com.br | www.minhacarreira.com | www.mare-vix.com

2010/7/28 Bruno D'Alessio <bruno...@gmail.com>

[Bruno D'Alessio]

Fala Ferrari,
você meio que completou minha resposta, a organização por tipos que eu faço é subgategorizada pelo seu contexto.

 

Não centralizo todas as interfaces do projeto em um mesmo diretório.

 

Mas centralizo todas as interfaces da minha camada em um diretório.

 

Já vi projetos bem grandes fazendo isso, centralizando cada tipo em seu diretorio independente de contexto  / camada.

 

Virá um saladinha bem legal.

 

 

Abs,

[Rodrigo Vieira]

Acho mais fácil pensar na estrutura de namespaces que faria sentido
pra vc, e adotar uma divisao de diretórios que espelhe isso. Depois
fica mais fácil achar as coisas tb.

Tendo isso em mente, e concordando com o q disse o Denis e o Ricardo,
acho que faz mais sentido encontrar uma interface dentro de um
namespace de dominio, infra etc, do que num namespace
"MeuSistema.Interfaces".

2010/7/28 Denis Ferrari <denis....@gmail.com>:

> Não me parece legal a organização por tipos. O domínio é dividido em pacotes
> (de negócio), e todo tipo criado será armazenado em seu respectivo pacote,
> sem divisões que não dizem respeito ao domínio propriamente dito.
> Abraços!
>
> Denis Ferrari - "Faça pouco, faça sempre e faça direito"
>
> Quer aprender TDD?
> www.heroisdati.com/tdd-para-iniciantes-para-quem-quer-comecar-e-nao-sabe-como/
>
> www.denisferrari.com
> www.mindworks.com.br | www.msdev-es.com.br | www.minhacarreira.com |
> www.mare-vix.com
>
>
> 2010/7/28 Bruno D'Alessio <bruno...@gmail.com>
>>
>> A estruturação de diretórios diz respeito a organização.
>> Existe alguns documentos na WEB, bem interessantes sobre isso.
>>
>> Eu pessoalmente gosto de dividir cada "tipo" em seu diretório.
>>
>> Quanto a projetos do VS, você dividir seu dominio em mais de um projeto,
>> eu recomendo para projetos "gigantes", onde talvez, você desacoplar,
>> a estrutura fisica gere beneficios.
>>
>> Quando não, pode-se centralizar sem temor algum, seu dominio em apenas um
>> projeto.
>>
>> Desde que a divisão / hierarquia das camadas esteja evidente na sua
>> solução e sua estrutura de diretórios facilite a localização dos arquivos,
>> fique a vontade.
>>
>> Abs,

[Juan Pedro A. Lopes]

Err, como eles chamam isso mesmo? Err... aplicação n-tier?

Sigh.

Kind regards,
Juan Lopes

http://qrcode.juanlopes.net

[Bruno D'Alessio]

Esse é um ponto que creio que todos vivem em constante evolução.

 

Eu prefiro dividir o diretório macro pelas minhas camadas.

E dentro da macro subdividir por hierarquia de namespace

 

E dentro delas por exemplo:

dir Dominio;

dir Dominio.Entidade;

dir Dominio.Entidade.Interface;

Por ai, não tem muito segredo não.

 

Abs,

[Rodrigo Braga]

realmente, refletir o namespace parece mais interessante!

2010/7/28 Bruno D'Alessio <bruno...@gmail.com>:

>> >> Em 28 de julho de 2010 12:30, Ricardo Simões <rsc...@gmail.com>

--
Att.,
Rodrigo Braga

[Ricardo Borges]

Seguindo as linhas do DDD você precisa subdividir seu domain em módulos. Quando um domain é grande fica impossível você compreender por exemplo 100 entidades em agregação.

Em módulos por funcionalidade do sistema isso fica mais compreensível, em cada módulo você só precisa das entidades até a fronteira das entidades que são necessarias para a funcionalidade que o módulo se propõe a modelar.


Ricardo

>> >> Em 28 de julho de 2010 12:30, Ricardo Simões <rsc.net@gmail.com>

--
Ricardo Borges

[Denis Ferrari]

Realmente não curto essas subdivisões.

O próprio domínio vai dizer quais são os namespaces necessários, criar separações por tipo é como dividir uma sala de aula em americanos e asiáticos, você não "Organiza", só separa.

Ex.: No namespace Financeiro eu tenho um repositório de Clientes. Não vejo sentido em separar os repositórios do resto do namespace, já que pelo domínio o mesmo deveria estar na raiz.

[Daniel]

Rodrigo,

Depende do ponto de vista.
Do ponto de vista da equipe de desenvolvimento, realmente parece mais
interessante. Mas do ponto de vista do negócio, não é nada interessante
separar as entidades/interfaces por este tipo de separação.

No livro, o Evans explica que este tipo de separação (Dominio.Entidades,
Dominio.Interfaces...) "amontoa" objetos que conceitualmente não possuem
coesão. Segundo ele: "The packages tell a story, but is not the story of
shipping; it is the story of what the developer was reading at the time"

Ao invés disso, ele sugere que seja feita uma divisão do tipo:
Dominio.Cliente
Dominio.Faturamento
Dominio.Entrega

Ou seja: "We should be looking for the cohesive concepts and focusing on
what we want to communicate to others on the project."
Desta forma, "The Module names contribute to the team´s language".

No Dominio.Cliente, por exemplo, deverão existir entidades, objetos de
valor, interfaces, factories que façam sentido para o contexto de cliente, e
assim por diante nos outros diretórios. No final das contas essa acaba sendo
a melhor divisão do ponto de vista da equipe também, pois se você tiver que
fazer alguma manutenção em Cliente, você encontrará em um mesmo diretório as
entidades/interfaces relativos a Cliente que você provavelmente precisará
alterar em decorrência de alguma alteração.

Abs!

-----Mensagem original-----
De: dotnetar...@googlegroups.com
[mailto:dotnetar...@googlegroups.com] Em nome de Rodrigo Braga
Enviada em: quarta-feira, 28 de julho de 2010 14:21
Para: dotnetar...@googlegroups.com
Assunto: Re: [dotnetarchitects] Dúvida sobre organização no Domínio

[Denis Ferrari]

Evans é o cara. :)

Abraços!

Denis Ferrari - "Faça pouco, faça sempre e faça direito"

Quer aprender TDD?
www.heroisdati.com/tdd-para-iniciantes-para-quem-quer-comecar-e-nao-sabe-como/

www.denisferrari.com
www.mindworks.com.br | www.msdev-es.com.br | www.minhacarreira.com | www.mare-vix.com

2010/7/28 Daniel <daniels...@gmail.com>

>> >> Em 28 de julho de 2010 12:30, Ricardo Simões <rsc.net@gmail.com>

[Rodrigo Braga]

Obrigado Daniel

Avaliando a mensagem é interessante o fato de que algo tão óbvio não
soou natural de imediato para mim (e muitas outras pessoas acredito
eu)

2010/7/28 Daniel <daniels...@gmail.com>:

[Rodrigo Vieira]

Daniel,

Nao sei se essa resposta foi pra mim mesmo ou pra outra pesoa, mas de
qq forma o que eu quis dizer na mnha mensagem vai de acordo com o q vc
disse aí: primeiro eu procuro pensar em termos de namespaces que façam
sentido pra aplicação (e no caso de DDD seria dentro dessa divisão q
vc exemplificou) e aí eu crio os diretórios (e projetos) espelhando
essa divisão. No sistema legado em que trabalho a divisão de
diretórios é por tipo (Interfaces, Exceptions etc), totalmente
desconectado da hierarquia de namespaces, então achar onde fica o
código pra uma coisa é sempre demorado.

- Rodrigo

2010/7/28 Daniel <daniels...@gmail.com>:

[Daniel]

Era pro Rodrigo Braga, que abriu a thread. Eu respondi em cima de um e-mail
dele...
Você deve ter confundido porque ela chegou depois da sua (e também porque eu
não especifiquei o sobrenome - desculpe-me).

Abs.

-----Mensagem original-----
De: dotnetar...@googlegroups.com
[mailto:dotnetar...@googlegroups.com] Em nome de Rodrigo Vieira
Enviada em: quarta-feira, 28 de julho de 2010 15:20

[Rodrigo Vieira]

Hehehe beleza, depois eu mesmo entendi, mas já era tarde :P

2010/7/28 Daniel <daniels...@gmail.com>: