| Autor |
Mensagem |
|
|
igorCouto wrote:
Para continuar alimentando os mappers sem precisar dos DTOs internos, podemos usar um modelo publish-subscribe disparado/alimentado na camada de services.
Essa é uma solução interessante, apesar de aumentar um pouco a complexidade, pois não estava considerando mensageria nesse problema. Eu estava pensando em deixar o banco único - uma única tabela "cliente" e deixar as coisas sincronas, apesar que cada vez mais estou vendo que isso vai ser impossível se eu quiser realmente deixar os domínios e serviços independentes.
igorCouto wrote:
podemos separar os jobs entre units (+ rápidos e frequentes) e atdd (noturnos por exemplo).
Uma dúvida: Você está usando essa estratégia hoje em algum projeto? Seus testes de integração demoram tanto assim para rodar? (é provável que meus testes de integração entre domínios rodem direto, pois as equipes vão gerar muitas funcionalidades por dia).
|
 |
|
|
Quem diz que o mercado adotou Orientação a Objetos deveria ficar 1 mês comigo visitando clientes e ver os DTOs / Datasets voando por aí.
O fato de você adotar uma plataforma que permite que você use Orientação a Objetos não faz o seu sistema automaticamente ser OO.
|
|
|
|
Amigos(as),
Imaginem que eu estou fazendo um ERP e tenho uns 15 domínios internos. Só para exemplificar, eu tenho base.Cliente, faturamento.NotaFiscal e vendas.Pedido (cada empacotamento seria um domínio). Problema: eu quero deixar esses domínios bem separados, pois eles serão desenvolvidos por pessoas diferentes e para tal, usarei Context Mappers como serviços que integração os domínios. Como exemplo, NotaFiscal tem Cliente, porém, só usa algumas características de Cliente (seria um faturamento.Cliente, talvez um subset de base.Cliente).
Minha dúvida:
1. Como vocês têm feito esses Mappers? Se usam serviços é possível fugir de DTOs internos mas garantindo uma independência entre a estrutura do DB?
2. E os testes? Qual estratégia vocês tem usado com total segurança? Nesses casos estou achando os Mockings muito frágeis, pois preciso garantir a independência entre módulos (domínios), porém, quero ter segurança que a integração contínua me mostre claramente as quebras da integração.
(tenho mais discussões, mas só essas para começar)
|
|
|
|
Se você achar um MER em todo o OpenUp EU TE DOU UM PRÊMIO.
Pensando no Uncle Bob "Aquilo que matou o RUP vai matar o Agile também", vou blogar sobre isso também...
|
|
|
|
Francisco Miguel wrote:Da uma olhada para ver se ficou bom!!!
Você não precisa daqueles includes! Include é uma ferramenta para reutilizar comportamentos. Se você não vai reutilizar não há razão deles existirem.
|
|
|
|
Essa dúvida é bastante comum no meu curso.
Mas, ator é aquele que interfaceia diretamente com o sistema. Se o Aluno só está conversando com a Recepcionista, e esta usando o sistema DIRETAMENTE, então, só ela é Ator. Se alguém não concordar com isso, escreva a narrativa desse caso de uso com o Ator Aluno por favor...
O Craig Larman escreveu uma VIAGEM sobre algo chamado "Ator Coadjuvante" no livro dele, mas nenhuma outra obra concorda com esse ponto de vista. Nem mesmo o Jacobson que foi o criador dos casos de uso.
|
|
|
|
Foi só um exemplo. Como falei, dentro de <<service>>Faturamento você vai ter um monte de coisas, nada impede de um serviço chamar o outro. Você pode até dizer que esse service atua como uma Façade, mas para o domínio isso é irrelevante. Um service pode ser uma façade (mas não por isso você vai deixar de chamá-lo de service).
|
|
|
|
Já leram o beabá?
http://www.agiledata.org/essays/culturalImpedanceMismatch.html
Esse aqui é o mais importante:
http://www.agiledata.org/essays/drivingForces.html
Resumo: Projetos OO são os objetos que dirigem a construção do seu modelo de banco. Cuidado com o DBAzinhos que querem manter seus empregos. Eles ficam com aquelas masturbações mentais do tipo "ah... esse indice tá errado... ah... esse relacionamento deve ser trocado... ah... isso não tá normalizado..."... Nesses dias com Hibernate, CouchDB, Caching de Objetos e outras coisitas mais os DBAs perderam bastante "poder". Já faz uns bons 5 anos que não sinto falta deles nos meus projetos. Melhorar a performance do banco é algo que qualquer programador deve saber...
|
|
|
|
laudenpower wrote:Bom isso varia em função da metodologia que se estiver utilizando, por exemplo,no OPENUP o diagrama de classes vem antes de qualquer coisa na fase de elaboração...
Amigo, aonde você leu isso no OpenUP?
|
|
|
|
Particularmente, apesar de correto, o exemplo do banco/transferência não é muito bom. O service é uma classe que coordena uma transação que não é naturalmente alocada a nenhuma entity. O exemplo que forneço no meu curso é o faturamento de um Pedido. Quando um pedido é faturado:
1. O pedido é verificado
2. Uma nota fiscal é gerada
3. Duplicatas são geradas
4. Um estoque é atualizado
5. O limite de crédito do cliente é atualizado
6. etc... etc... etc...
Alguns podem dizer que podemos alocar essas responsabilidades à Pedido.faturar(). Essa operação pode até existir pela Ubiquitous Language (afinal, o cliente DIZ que pedidos são faturados), mas a orquestração (não sei se essa palavra existe) de tudo isso acima são responsabilidades muito grandes para o próprio pedido. Seria legal que ele delegasse isso para um <<Service>> Faturamento (podendo ser uma estratégia de Pedido).
Logicamente, esse serviço existe porque isso faz sentido para o usuário (é DDD que estamos falando, certo?). É a classe Faturamento que lida com as coisas que o cliente entende como sendo o Faturamento. Nada impede também que um serviço acione outros serviços do domínio.
|
|
|
|
[IMHO] Cara, acho que se você comparar qualquer coisa Java com Ruby no quesito "especificação executável" será uma covardia, excetuando-se pelo FITNesse.
Olha isso aqui:
http://blog.caelum.com.br/2009/02/28/behavior-driven-development-com-junit/
|
|
|
|
|
Qualquer solução que for colocada aqui sem ter os requisitos do que você espera das "Pessoas" é mera especulação. Talvez você não precise de factories, nem de herança e talvez nem mesmo o sistema.
|
|
|
|
Não tem muita relação com acoplamento. Nas duas alternativas a classe está dependendo da Classe X. Se a classe X é abstrata, aí sim a alternativa 1 é menos acoplada. Se não é, tanto faz...
Para falar a verdade, na alternativa 2 você está com uma dependência maior com relação à criação do objeto, mas, como disse, a dependência existe nas duas opções.
|
|
|
|
|
Er... seria possível você mandar uns 2 - 3 exemplos mais palpáveis do que você quer fazer?
|
|
|
|
Felagund wrote:
Prefiro esperar 10 anos por uma especificação desde que ela ja esteja madura e melhor de usar.
O tempo de desenvolvimento não quer dizer nada.
Eu realmente espero que seus clientes não escutem isso....
|
|
|
|