| Autor |
Mensagem |
|
|
http://ivarblog.com/2007/03/12/software-is-international/#comment-276
Eu e o Rodolpho da IBM fizemos uma pesquisa na semana passada. Componentes datam de 1967 em Assembly. Ivar Jacobson, pai da UML, do RUP e dos Casos de Uso é também pai dos Componentes....
|
 |
|
|
ViniGodoy wrote:Se for a definição de componente mais recente:
"Componente é a representação gráfica de um Objeto", então, logicamente, foram os objetos.
De onde vc pegou isso?
|
|
|
|
Da série polêmicas que ensinam, pergunto:
O que veio primeiro: COMPONENTES ou OBJETOS?
(pode colocar a sua opinião empírica - não perca a semana pesquisando como eu)
|
|
|
|
A.L wrote:"Um módulo tem que ser identificável por si só."
Vejo que isso é a relação com a Ubitiquous Language e não com analisar dependências...
|
|
|
|
|
Joel... não é tão simples assim na minha opinião. Note que o conceito de Package pode mudar dependendo da linguagem (como explicado no próprio livro). Alí ele não está se referindo simplesmente a packages do próprio Java.
|
|
|
|
Minhas considerações:
http://blog.aspercom.com.br/2008/07/29/sprint-iniciado-nao-se-mexe/
Resumo: Sprint iniciado não se mexe.
|
|
|
|
Exatamente Rodrigo, separar módulos é para organizar, melhorar a visão, diminuir a complexidade, testar modularmente...
Vejo poucas pessoas fazendo isso, e vejo que o simples empacotamento de classes não colabora para os itens acima.
Vcs usam Façades para integração entre módulos?
|
|
|
|
Rodrigo Carvalho Auler wrote:Um módulo pode acessar informações do outro. Mas se você for pensar em reuso, o maior desafio é deixar os módulos desacoplados pra você poder reutilizar um módulo independentemente dos outros.
Imagine que um módulo pode ter umas 30 classes, e outro módulo tem também 30 classes. Essas classes podem enviar mensagens entre si livremente? Como vc desacopla hoje?
|
|
|
|
sergiotaborda wrote:
....
Leia módulos aqui como Modules no contexto da DDD e não no contexto comercial/licença e etc...
(acho estranho aqui que qualquer discussão sobre repositórios traz um monte de gente, mas discussão sobre Modules e Aggregates da DDD - que são mais importantes - ninguém discute)
|
|
|
|
Diego,
Aggregates/Roots são mais utilizados para vc gerenciar a comunicação que ocorre entre entidades importantes principalmente para reduzir a complexidade e gerenciar melhor dependências. Se sua aplicação é simples não há motivos para você utilizar. Na DDD vejo 3 "níveis" para vc combater complexidade:
1. Coesão e acoplamento nas suas entidades, value objects, services, repositórios
2. Separar Aggregates para ter um Root que atue como um gerenciador da comunicação entre vários Roots
3. Separar Modules contendo vários Aggregates, quebrando ainda mais funcionalmente uma aplicação grande
4. Separar Bounded Contexts (quando a UL começa a vazar, trata-se de domínios diferentes)
O que vc escreveu não está muito claro. Faz um yuml.me para clarear as idéias...
|
|
|
|
|
Nas aplicações de vocês os módulos se acessam livremente? Estoque precisa de informações de Faturamento, que precisa de informações de Vendas e assim por diante.
|
|
|
|
Amigos(as),
Vocês consideram módulos e pacotes/namespaces a mesma coisa? Como vocês modularizam a aplicação de vocês e o que buscam com isso? (estou escrevendo sobre isso e gostaria de avaliar a visão do mercado)
Abrações!
|
|
|
|
Vamos aos exemplos clássicos.
Agregacão: Simplesmente é um relacionamento do tipo "Parte-Todo" e isso não vai mudar praticamente nada no seu código. Agregação simplesmente é uma informação do projeto [ Rumbaught]. Na dúvida, não use. É isso mesmo que estou falando. Se for gerar confusão no seu projeto não use, pois Agregação não tem semântica na UML.
Exemplo Clássico:
Explicação: Simplesmente uma Equipe é o Todo e as Pessoas são as Partes. Nada muda se você simplesmente tirar aquele diamante dali.
Composição: é o relacionamento mais forte da UML. A idéia da Composição é que o conjunto todo de classes é como se fosse uma única coisa. Uma instância das partes não pode ser compartilhada e quando a classe forte (da do diamante) morre todos os compostos morrem junto.
Exemplo Clássico:
Um item pedido não pode estar associado a dois pedidos simultaneamente. Quanto o pedido morre os itens também morrem.
http://martinfowler.com/bliki/AggregationAndComposition.html
|
|
|
|
mochuara wrote:
Defina o que é "ferir o Scrum" e porque eu deveria me importar com isto.
O que você comumente customiza no Scrum?
[
mochuara wrote:
Desenvolvimento não agil é desenvolvimento cascata. RUP é cascata.
Bem, por mim a thread termina aqui... vc demonstrou completo desconhecimento do assunto. Boa sorte.
|
|
|
|
mochuara wrote:
Customizar Scrum é considerado um equivoco desde quando? 
Lá vamos nós de novo... Me fala UMA customização que você pode fazer no Scrum sem ferir o Scrum.
mochuara wrote:
Não misture as coisas, o que matou o RUP não foi sua customização, pelo contrário, foi sua falta de flexibilidade.
Qual falta de flexibilidade? Fontes desse ponto de vista? O RUP é a metodologia mais flexível que existe. É a mais aberta a customização. Qual é a sua opinião? O que mata o RUP?
mochuara wrote:
Scrum pode sim ser muito util no desenvolvimento não agil.
O que vc quer dizer com isso? O que seria um desenvolvimento não ágil? Cascata? Sem auto-organização? Sem programadores?
|
|
|
|