-
-
Save rcarneiro/433106 to your computer and use it in GitHub Desktop.
| Discussão sobre os motivos de não iniciar a modelagem de domínio | |
| de um sistema pelo banco de dados. |
Twitts
Rodrigo Yoshima:
http://twitter.com/rodrigoy/status/15854847164
http://twitter.com/rodrigoy/status/15854777283
Luca Bastos
http://twitter.com/lucabastos/status/15856811029
http://twitter.com/lucabastos/status/15855988015
http://twitter.com/lucabastos/status/15855420682
http://twitter.com/lucabastos/status/15855270536
http://twitter.com/lucabastos/status/15855110857
http://twitter.com/lucabastos/status/15855018550
http://twitter.com/lucabastos/status/15854864698
http://twitter.com/lucabastos/status/15854622000
Christiano Milfont
http://twitter.com/cmilfont/status/15855145895
Rafael Ponte
http://twitter.com/rponte/statuses/15855706958
http://twitter.com/rponte/statuses/15856521489
http://twitter.com/rponte/statuses/15856151815
Eliziário
Como já falei no twiiter uma vez (@rodrigoy), em 1997 ou algo do tipo estava lendo um livro do C.J. Date (um dos pais da teoria relacional de BDs) e pesquisando achei um artigo dele que falava contra o uso de stored procedure e triggers. Ele dizia que "a função do banco de dados é guardar dados", e alertava quanto ao uso de procedimentos armazenados, estratégia que inicialmente foi proposta pela Oracle e sequida pela Microsoft. Eu vejo que a coisa que mais colabora no mundo para vendor lock-in são as stored procedures.
Isso que escreví acima não tem 100% relação com a discussão, porém a OO nos trouxe um excelente benefício para unir dados e comportamentos. Alta coesão é uma boa idéia. Defendo que um sistema OO é baseado em classes. Usamos OO também para gerenciar dependências, e aí, quando falamos sobre BDs, a maioria das empresas tem um banco monolítico (acabo de criar um nome de anti-pattern "insane integration database") e isso é muito ruim.
No ano passado fiz umas 3 ou 4 apresentações em eventos falando que o mercado em geral está adotando algumas coisas boas como testes automatizados e tal. Porém, o correto particionamento [Booch] em módulos funcionais é pouco utilizado. Ou para quem quiser ficar na moda Domain-Driven Design, separação de contextos é pouco utilzada [Evans].
Começar a modelar uma aplicação pelo banco de dados só vai piorar este cenário. Pelo que me lembro, começamos a mudar a nossa visão e usar OO exatamente porque procedures e data-stores são muito ruins para gerenciar dependências [Nilsson].
Só para completar com o que escrevi agora no twitter e que reflete o que entendo por modelagem.
Para mim, modelagem é a primeira coisa a fazer quando se quer incluir alguma facilidade nova no sistema ou quando se puxa uma nova história. As ferramentas ideais são lápis, papel, canetinha, lousa, CRC cards, post-its. Nesta etapa se usa tudo inclusive o bom e velho fluxograma (prefiro diagrama de atividades, de casos de uso ou de sequencia) que geralmente é bem entendido pelo cara de negócio.
Na cabeça da gente dados se mistura com comportamento e isto vem bem antes do DDD. O sistema para a gente é um todo porque muitas vezes a gente enxerga um instantâneo da aplicação. Mas ao pensar onde ficam os dados, aparece o desenhinho do BD.
O que já vi acontecer com sucesso é o caso em que a propria definição das entidades envolvidas já é uma figurinha parecida com os antigos diagramas de fluxo de dados do Chris Gane indicando o que vai no BD. No caso de um trecho de sistema com NFs e seus itens, não vejo mal nenhum em já colocar logo de cara o que contem cada entidade.
Ruim para mim seria primeiro definir um banco de dados físico e congelado para a apartir dele fazer a modelagem. Sei bem que isto ocorre porque já vivi em um ambiente assim. O cliente disse: quero esta nova coisa mas os dados são estes aqui e zé fini.
Levando em consideração os tweets que enviei, o que abordei foi mais ou menos o que o Yoshima falou. Até por que no ambiente em que tive essa experiência havia colunas e tabelas que, ao decorrer do projeto, vimos que não eram necessárias ao domínio da aplicação. Aí vem o problema de BDUF que vivi.
Acho que a modelagem de bd e OO possam correr juntos, até porque há ferramentas que fazem o export, como o Hibernate em Java.
Felipe
BDUF é praticamente inevitável e quase sempre existe, pelo menos um pouco. BD às vezes também precisa de refactoring. Se não for por BDUF, será porque não consideramos alguma coisa.
Não discordo do Rodrigo quanto ao uso de ferramentas como o Hibernate. Só que para mim isto é um detalhe que pode ser usado ou não na hora de criar as classes oriundas da modelagem (As do Rails são até melhores do que as do Hibernate)
Ainda prefiro modelar as classes no papel. E quando digo modelar as classes, estou pensando apenas no que vai representar minha solução enquanto são apenas um retangulozinho no papel. Tenho dificuldades de enxergar a necessidade de existir e o relacionamento entre classes direto na IDE.
Lucca, BDUF é "BIG design up-front"... Design up front não é um problema. Todos os projetos que trabalho existe alguma modelagem, seja em cards, quadro-branco ou papel A4. O BDUF é querer modelar o sistema em detalhe logo no início.
Uma questão que tenho visto nesses quase 10 anos que eu estudo sobre modelagem é que algumas pessoas são mais visuais do que outras, e por isso a opinião sobre modelagem pode variar bastante. Eu gosto de modelar visualmente e acho que modelos visuais (mais uma vez, em papel, lousa-mágica, quadro-branco e etc...) fornecem uma visão excelente, principalmente em reuniões de planejamento de release ou iteração.
Rodrigo
Plenamente de acordo. Para mim, a modelagem visual só tem vantagens. Ajuda superar minhas dificuldades de enxergar o conjunto e principalmente ajuda explicar para o cara de negócio, seja ele um PO, seu chefe ou alguém de um cliente externo.
É que muitos desenvolvedores se prendem a siglas e se bloqueiam com medo delas. Não há mal nenhum em modificar o que inicialmente se imaginou como necessário. Os xiitas dizem que quando se corta coisas feitas no início aconteceu BDUF. Para mim isto é normal.
E voltando a pergunta inicial, acho que é o que mais acontece no dia a dia. Mesmo em um sistema em evoução, iterações posteriores dependem de bancos de dados definidos em iterações iniciais e eventualmente que já foram liberadas para produção. Aí é aquela história de só poder mexer de madrugada, com beneplácito de DBAs que já se apossaram do sistema e tudo o mais. É do dia a dia do desenvolvedor.
Resumindo: modelar com BD pronto talvez seja mais comum do que partir do zero.
http://www.agiledata.org/essays/impedanceMismatch.html