Mensagens enviadas por: feliperod
Índice dos Fóruns » Perfil de feliperod » Mensagens enviadas por feliperod
Autor Mensagem
Interessante o desafio! Vou olhar com mais calma depois!
Cara... estou trabalhando nele, mas numa velocidade menor do que eu gostaria. Se alguém estiver a fim de me ajudar, numa atividade open source, eu ficaria muito feliz e o projeto!

O evento tá muito legal mesmo. É uma iniciativa bacana, pois a Globalcode convidou várias empresas e grupos de usuários para que cda um realizasse um evento dentro do TDC. Esses eventos são as trilhas.

O nível das palestras também está animal. Na trilha de Ruby, acabei de confirmar o José Valim. Brazuca commiter do Rails e vencedor de alguns prêmios da comunidade Ruby.

Vale muito a pena!
Eu também vou palestrar no evento. Teremos muitos assuntos interessantes e o foco é mostrar as diversas oportunidades na área de TI (mais ligadas a Java).

Vai ter também um debate sobre empreendedorismo. Então se você pretende ou deseja ter seu próprio negócio, vai lá que vai ter assunto pra você.


Só que acho que as inscrições estão quase esgotadas (se já não esgotaram). Por isso, corre pra tentar pegar uma vaga.


Ah.. pra galera que mora longe, um passarinho me contou que tem discussões rolando pra levar o evento pra vários lugares no País. Fiquem espertos e contatem os caras da GC pra ajudar a isso se realizar.
Olá Fred,

Realmente há um erro no código.

Era pra ser o seguinte:



Vou me comunicar com o Eduardo para ver como fazemos pra imprimir uma errata na próxima edição.

fredferrao wrote:
Rafael Afonso wrote:Olá:

Queria fazer uma observação sobre a matéria de Scala. Na listagem 5 temos a seguinte função:

No escopo da função externa (methodWithLocalFunction) não está definido o que é b, apenas para o escopo de aFunction. O código não deveria ser como abaixo?

Ou melhor ainda:

Para evitar confusão com o nome das variáveis?

Para os administradores: Ao usar a tag code não tem como indicar para usar o Syntax highlighting de uma determinada linguagem? Como Scala, JavaScript, Ruby, etc...

Grato,


Sera que não era pra ser assim??


Galera,

Vai rolar outra turma no próximo dia 12/12. Acessem o site pra ver e quem nào foi, não perca. É uma iniciativa gratuita para a comunidade.

Ahh... além disso, vai rolar um Dojo com o Program-ME. Muito legal também.
Normalmente depende da estratégia de persistência que você utilizar a forma que isso será feito. Mas a camada de infra pode depender da camada de modelo.
AGAraujo wrote:
tnaires wrote:
AGAraujo wrote:Como podemos implementar um Repositorio (na Infra) sem depender das Entidades (no dominio)?

Um repositório não pertence à infra, e sim, ao domínio. Ele pode depender da infra pra realizar suas tarefas.


Não disse que Repositorio é da Infra e sim sua implementação:

AGAraujo wrote:...implementar um Repositorio (na infra)...


Mas beleza, estamos concordando até aqui... o lance está em:

como implementar o repositorio na infra sem que ele dependa do domínio?

vlw novamente tnaires


O repositório faz parte do domain model, cuida do ciclo de vida dos objetos de domínio. Dessa forma, não existe repositório se nào existir objetos de domínio. Consequentemente, o repositório depende dos objetos de domínio.
Link_pg wrote:meu nome é Eduardo, ta na assinatura (a não ser que vc acesse de leitor RSS) hauehaaeuehu

então cara, vou mandar email sim, inclusive queremos começar a fazer o projeto mesmo, pra apresentar la pro pessoal docente da facul... logo menos a gente agita até uma breja com uma porção de camarão na praia aheuheauaehuaehu


Heheh... nào acredito que não li na sua asinatura. hehehehe

Abração
Link_pg (Preciso saber seu nome.... hehehehe)

Vamos agitar aquele negócio da comunidade em Santos cara...
Me manda um email que a gente agita!
Link_pg wrote:Processo NIKE foi o melhor... com PHP ja seria um Processo ADIDAS: "Impossible is nothing" hauehuaehueahuaeh

Ah Felipe, show de bola a apresentação!

A primeira vez que eu ouvi sobre o processo NIKE foi numa palestra do Juan Bernabó.
Más é um bom processo. =)

Fico feliz que tenham gostado da apresentação galera. Espero nos vermos no mini curso de TDD agora, que será dia 24/10.

Abração
Desenterrando um post antigo, porque o achei em uma consulta no google. =)

frocchagas wrote:Aliás, pensando nisso me surje uma dúvida que, espero, alguém mais capacitado irá nos ajudar...
Um Service pode ser visto como uma espécie de Façade?


Há dois tipos de Services Layers aceitáveis: Domain Facade e Operation Script.

O Domain Facade é uma fina camada de facades que determina os limites de território do Domain.

O Operation Script, são classes que encapsulam operações do Domain e contém lógica. Tá mais pra um decorator.

Ambos são bem simples tecnicamente, o problema consiste em determinar quais são as operações que serão disponibilizadas por estes services. Daí a grande necessidade de entender o que realmente é o Domain Driven Design.
Thiago Senna wrote:
sergiotaborda wrote:
Thiago Senna wrote:
sergiotaborda wrote:Bom, então só posso concluir que vc não faz testes automáiticos no seu software... porque só para facilitar os testes já é uma benção para mim.


Crio os testes automatizados numa boa. Conclusão precipitada, não acha?


Não acho. Aposto que vc tem grande dificuldade em testar o seu sistema sem ui e sem banco de dados e que provavelmente não usa um servidor de continuidade.


Não utilizo servidor de continuidade. Testo sem a camada de UI numa boa. Testo Domain + Persistência pois não acho necessário separá-los. Para casos onde é muito importante testar o negócio sem persistência é só usar mock. Qual é a dificuldade nisso?


Não vou opinar se está certo ou se está errado. Mas eu daria uma dica para você ler sobre benefícios do TDD. O TDD consiste em escrever o teste antes do código. Isso facilita o design de cada classe. Individualmente. Nesse caso, por nào separar o Domain da persistência, fica claro que não são testes unitários.

Outra coisa é que dificuldade para testar individualmente siginifica, na maioria dos casos, problemas de design.

Vale a pena investigar.
euprogramador wrote:
feliperod wrote:
Seria ótimo se você pudesse ir no mini-curso gratuito que vai ter. Eu explico essa parte.


Onde vai ser? eu sou de brasília.

Vai ser em sampa... =(
Mas quem sabe a gente marca um em Brasilia qualquer dia desses. Só arrumar lugar e rachar as despesas da viagem entre a galera aí que eu vou. =)
QQ coisa me contata em PVT.
euprogramador wrote:
O que acontece é o seguinte eu tenho os ManagedBeans do jsf que pertence a camada de aplicação, e coloquei a interface do repositório na camada de dominio e a implementação na infraestrutura, desta forma que demonstrei o repositório realmente sabe demais sobre a infraestrutura, o que recomenda então é criar um objeto que será responsável por acessar o banco e ficará na infraestrutura, e tanto o managed bean e o repositório o acessaria?

ficando assim



talvez assim fique melhor. Não sei.. tem que avaliar o caso.


euprogramador wrote:
O repositório seria também poderia acessar o QueryObject, mas agora ele tem uma interface mais especifica como:

Seria assim?

Acho que essa interface pro repositorio está boa sim. O nome do método é bem explicativo. Talvez fique melhor se você achar um jeito de dizer que é ordenado. Isso normalmente é resolvido por named paramaters em linguagens dinâmica. No Java pode ser inviável. Mas vale tentar.

euprogramador wrote:
Outra, o que tenho notado com DDD é que o código de negócio (Service) fica bem pequeno, mas temos muito código nas camadas para suportar o serviço, é assim mesmo?

O Código de negócio deve ficar na camada de domain. Nos Services, Entities, Value Objects.
É um assunto mesio extenso pra explicar pelo forum sem ser abstrato demais. Seria ótimo se você pudesse ir no mini-curso gratuito que vai ter. Eu explico essa parte.

Mas de qq forma, as outras camadas não devem conter regras de negócio. Verifique se o Service que você mencionou é o Service que o DDD menciona (conceitualmente). Verifique se a sua camada de domain possue um limite claro... Verifique se cada camada está cumprindo unica e exclusivamente o seu papel.
Ah.. cuidado pra não confundir regra de negócio com regra de apresentação.

E é isso. =)
 
Índice dos Fóruns » Perfil de feliperod » Mensagens enviadas por feliperod
Ir para:   
Powered by JForum 2.1.8 © JForum Team