Frase da Semana de 24 à 30/05

Cue Pink Floyd ripoff, “we don’t need no static contracts… hey, WSDL, leave that Web alone”

Essa é do Jim Webber, thoughtworker palestrante do "Falando em Java 2009", a respeito de WS-*. Para quem quiser entender melhor essa provocativa frase recomendo as seguintes leituras.

http://jim.webber.name/2009/05/26/85eb97fc-c601-4103-a6bc-e0f9a0adc10c.aspx

http://www.infoq.com/articles/webber-rest-workflow

Frase da Semana 03 a 09/05

"Software gets complex as you add more features to it. We all know that. Designers, developers, engineers, product managers, and your drunk neighbor would all agree. But, if you're not working directly on building software, it's easy to under-appreciate how quickly complexity happens."

Para quem se interessou na fonte desta frase segue o link do post.

Annotation no Spring 3.0

Saiu ainda a pouco a o Milestone 3 do Spring 3.0 . Dentre os novos recursos um que saltou aos olhos é a possibilidade usar annotations do Spring na definição de annotations customizadas. Com o perdão da licensa poética, alguma coisa como "composição" ou "herança múltipla de annotations". Como um exemplo vale mais que mil palavras segue o próprio exemplo do post de divulgação do Blog do SpringSource .

@Service
@Scope("request")
@Transactional(rollbackFor=Exception.class)
@Retention(RetentionPolicy.RUNTIME)
public @interface MyService {
}

@MyService
public class RewardsService {
…
}

Ou seja, as annotations do spring além de serem usadas como meta-dados nos beans, agora podem ser usadas como meta-dados na definição de meta-dados de sua aplicação. Alguma coisa como meta-meta-dados ou meta2-dados(ahahahahah) . Uma possibilidade interessante que emerge é observar duplicação na ocorrência de anotattions e criar uma annotation que agrupe elas. Quem já criou um repository com Spring 2.5 sabe do que estou falando.

@Repository
@Transactional
MyReposytory

E eis que surge o refactoring de annotations :)

Outra possibilidade é a criação de annotation que além de agrupar, traduzam conceitos mais próximos do negócio em questão.

Todo essa conversa de annotation anotando annotation só me faz lembrar meu chapa Eduardo Guerra, nas nossas conversas de cafezinho, antevendo o surgimento deste padrão. Espero que ao ler este post ele não faça o seu cromossomo X falar alto e exclame um sonoro "Que foi que eu falei". E que venham o Spring 3.0 RC1.

Frase da semana.

"Mutable state is actually another form of manual memory management: every time you over-write a value you are making a decision that the old value is now garbage, regardless of what other part of the program might have been using it."

Aos curiosos sobre a origem desta frase provacativa segue o link do post.

SpringSource joga pesado com a Sun

Em meu blog coloquei um post sobre a aprovação da JEE 6 pela JCP e o voto neutro da SpringSource. Vale uma lida!

O Javascript vai levando a melhor. E a Google com ele.

No meu blog postei um comentário sobre a briga dos browsers. Vale uma lida!

Abraços!!

One Model to rule them all !

Confesso que ainda que simpatize com Domain Driven Design e procure praticar alguns de seus conceitos, não conclui a leitura da "bíblia" do assunto. Ainda assim julgava ter um entendimento satisfatório, haja vista a leitura parcial da referência e a leitura de infindáveis posts que li nas comunidades de desenvolvimento.
Uma conclusão precipitada que tomei, baseado no meu conhecimento parcial do assunto, foi que um conceito chave desta disciplina era a existência de um modelo de domínio ÚNICO por aplicação, o qual acomodaria as regras de negócio, ou parafraseando o Senhor dos Anéis: "One Model to rule them all" .
Recentemente me deparei com a entrevista de um desenvolvedor/arquiteto de software de nome Greg Young, na Infoq, que me chamou atenção pelo fato deste praticar DDD em comunhão com Imutabilidade, algo que venho confabulando há algum tempo. Porém o que mais me chamou atenção foi o fato dele ter modelos de domínio distintos para escrita e para leitura de dados. Intrigado com essas peculiaridades de design pesquisei mais sobre o assunto e encontrei um blog do referido entrevistado no qual ele desenvolve melhor esses conceitos. A explanação culmina na seguinte afirmação.

O que é uma pá de cal na minha na minha ingênua conclusão sobre DDD: "One Model to rule them all" .
Juntados os cacos, resta recompor-me e aproveitar este incidente como motivação para dar continuidade a leitura da "bíblia" e para pesquisar sobre "domínio múltiplo". Como produto destas pesquisas espero responder as perguntas do tipo: Seria o design com "domínio multiplo" uma prática comum no mundo DDD? O "domínio múltiplo" é uma condição para se praticar DDD e imutabilidade? Quais os impactos na coesão do sistema? Isso não seria uma extrapolação Chiita dos princípios de design SRP e Command-Query Separation para arquitetura? Certezas poucas e dúvidas muitas!