| Autor |
Mensagem |
|
|
Trevas não se misturam com luz...
Fazíamos modelos lógicos usando MER tentando simular um Domain Model behaviour-less nos anos 80-90. Não funfava, abstração muito fraca...
Não há sentido usar análise estrutura para um projeto utilizando paradigma OO. Estamos em 2009. Modele objetos direto.
|
 |
|
|
sergiotaborda wrote: ......
Fontes por favor????
|
|
|
|
mochuara wrote:
Ter uma arquitetira executavel não faz sentido pra mim. Eu concordo com o Sergio, ninguém descobre uma arquitetura a ser utilizada no decorrer do projeto (pelo menos não deveria). Na verdade o termo arquitetura de caixinha se refere a utilizar a mesma arquitetura em todos os projetos, como se ela fosse algo executavel.
Em 2007 escreví um artigo com o Scott Ambler e o Jon Kern entitulado "O papel do Arquiteto". Segue o link com uma prévia:
http://blog.aspercom.com.br/2007/09/20/opapeldoarquiteto/
Quando escrevemos esse artigo chegamos a conclusão de 3 coisas muito óbvias. Um arquiteto:
1. Tem experiência variada
2. Elege uma arquitetura baseada nos requisitos (requisitos dirigem a arquitetura e não o contrário)
3. Deve ser embasado nos negócios da empresa (conhecimento do negócio forma um bom arquiteto)
Detalhe: TODOS os autores sérios defendem que uma arquitetura é executável. O que você quer dizer com uma arquitetura que não executa? Aliás, para que ela serve?
|
|
|
|
sergiotaborda wrote:
Tecnicamente arquitetura de um sistema não se programa, se escolhe. O que se programa é o design.
Como eu ainda não vi os videos vou me abster de mais comentários porque não sei se ele diz "architecture" ou "design".
Se for design ele tem razão. Se for arquitetura ele não sabe do que fala.
Sérgio, como assim? O que é arquitetura para você? Escolher o que? Liguagens? Frameworks? Se você acha que o Robert Martin não sabe do que fala seria legal vc escrever um artigo, citando fontes e provando isso...
A todos....Desde o método Objectory, pré RUP, nosso amigo Jacobson já falava que arquitetura é EXECUTÁVEL (e isso nos anos 70 e 80). Nenhum autor, diz que arquitetura são diagramas. O RUP que geralmente é o culpado pelas aberrações do mercado desde sempre disse que o fruto da elaboração é uma arquitetura provada com software funcionando (geralmente implementando alguns cenários complexos dos casos de uso mais importantes). E acredite, há projetos que você PRECISA provar a arquitetura antes de começar a entregar kilos de funcionalidades. Foco em arquitetura: uma das bases do RUP, resolva a arquitetura primeiro e você não terá problemas no futuro. Isso é válido para sistemas mais complexos, se você só usa arquitetura Toddinho (de caixinha), você nunca fez um software com riscos arquiteturais significativos...
Se um arquiteto não sabe codar ele não serve para nada. #ivory_tower...
|
|
|
|
É interessante ver que a OO foi simplemente ferramental para uma necessidade que já existia (interfaces como exemplo).
|
|
|
|
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...
|
|
|
|