Table Of Content© CasadoCódigo
Todos os direitos reservados e protegidos pela Lei nº9.610, de
10/02/1998.
Nenhumapartedestelivropoderáserreproduzida,nemtransmitida,sem
autorização prévia por escrito da editora, sejam quais forem os meios:
fotográficos,eletrônicos,mecânicos,gravaçãoouquaisqueroutros.
CasadoCódigo
Livrosparaoprogramador
RuaVergueiro,3185-8ºandar
04101-300–VilaMariana–SãoPaulo–SP–Brasil
CasadoCódigo Sumário
Sumário
1 Criando Software mais Próximo ao Cliente com Domain Driven
Design 1
1.1 DomaineUbiquitousLanguage . . . . . . . . . . . . . . . . . 2
1.2 ConstruçãodoDomainModel . . . . . . . . . . . . . . . . . . 2
1.3 ImplementandooDomainModel . . . . . . . . . . . . . . . . 3
1.4 DDD(quase)naprática . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Implementar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6 Repositórios,DAOs,Layersemuitaconfusão . . . . . . . . . 8
1.7 ConsideraçõesFinais . . . . . . . . . . . . . . . . . . . . . . . 10
1.8 Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 ProjetandoeCodificandoumaDSLInterna 13
2.1 Exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 BoasOportunidadesParaoUso . . . . . . . . . . . . . . . . . 23
2.3 Desvantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4 Persistência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5 Consideraçõesfinais . . . . . . . . . . . . . . . . . . . . . . . . 25
2.6 Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3 MelhoriaContínuadoCódigocomRefatoração 27
3.1 OqueéRefatoração? . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 Arefatoraçãonodia-a-dia . . . . . . . . . . . . . . . . . . . . 30
3.3 RefatoraçãoeExtremeProgramming(XP) . . . . . . . . . . . 35
i
Sumário CasadoCódigo
3.4 Exemploderefatoração . . . . . . . . . . . . . . . . . . . . . . 36
3.5 Cuidadosparaaplicarasrefatorações . . . . . . . . . . . . . . 51
3.6 Consideraçõesfinais . . . . . . . . . . . . . . . . . . . . . . . . 55
3.7 Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4 OsPrincípiosdaModelagemÁgil 57
4.1 Paraodesenvolvimentodesoftware,nãoexisteseparaçãoen-
tredesigneconstrução . . . . . . . . . . . . . . . . . . . . . . 59
4.2 Desenvolvimentodesoftware:humanasouexatas? . . . . . . 61
4.3 Acomunicaçãoricado“papelsobreamesa” . . . . . . . . . . 62
4.4 Rascunhos:umaformademodelagemeficaz . . . . . . . . . 63
4.5 Rascunhosparaobterqualidadeexternanosoftware . . . . . 65
4.6 AprofundaremdetalhesantecipadamenteéRUIM! . . . . . 67
4.7 Nãovolteparacasaparaescreverdocumentosderequisitos! 70
4.8 Utilizandoamodelagemparaobterqualidadeinterna . . . . 71
4.9 Conceitossempreprovadoscomcódigo . . . . . . . . . . . . 75
4.10 Conclusão. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.11 Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
ii
Capítulo1
Criando Software mais Próximo
ao Cliente com Domain Driven
Design
“”
–porSérgioLopes
Domain-DrivenDesigncaiunabocadopovo.Quemnavegaporfórunse
listasdediscussãosobreJavajápercebeuointeressequeDDDtemdespertado
naspessoas(aquinaCaelummesmotemosaltasdiscussõessobreoassunto).
E, junto com toda essa atenção, também aparecem muitas dúvidas e idéias
erradas.
OobjetivodesteartigoéserumaintroduçãoàDomain-DrivenDesign
1.1. DomaineUbiquitousLanguage CasadoCódigo
(DDD),mostrarsuasprincipaisidéiaseprovocardiscussõesemtornodeste
tematãopolêmico.
1.1 Domain e Ubiquitous Language
O ponto fundamental do DDD é o primeiro D, o Domain. Tudo gira em
torno desse tal de Domínio. O domínio é, em poucas palavras, o problema
quequeremosresolvercomoprogramaqueestamosdesenvolvendo.Alguém
(umcliente)temumproblemanaáreadeatuaçãodele(geralmentenadaaver
cominformática)econtrataumaequipedeprogramaçãoparaajudá-lo(nós!).
Segundo o DDD, é impossível resolver esse problema satisfatoriamente
sementenderdireitooqueacontecenodomíniodocliente.Nãobastaosde-
senvolvedoressaberemmaisoumenos:énecessárioentrarfundonodomínio
docliente.
Mas,éclaroquenossoobjetivonãoénostornarmosespecialistascomple-
tosnaáreadocliente,masapenascompreendê-la. Apalavra-chaveparaisso
aconteceréConversa. Conversaconstanteeprofundaentreosespecialistas
dedomínioeosdesenvolvedores.
Aqueles que conhecem o domínio em detalhes devem conversar com
aqueles que conhecem programação em detalhes. Juntos, tentarão chegar a
umalínguacomumemquetodosconsigamseentenderequeseráusadaem
todas as conversas. É o que o DDD chama de UbiquitousLanguage(UL):
uma língua baseada nos termos do domínio, não totalmente aprofundada
neste,massuficienteparadescreveroproblemasatisfatoriamente.
1.2 Construção do Domain Model
Duranteaconversaconstante,todosjuntoschegarãoaumconsensosobreo
Domínio.Osespecialistasdedomínio,eventualmente,criarãosimplificações
para facilitar a conversa; e os desenvolvedores podem introduzir conceitos
técnicossimples.
Com isso, todos criam um modelo do domínio, o DomainModel. Para
o DDD, é uma abstração do problema real, desenvolvida em parceria pelos
especialistasdodomínioedesenvolvedores.
2
CasadoCódigo Capítulo1. CriandoSoftwaremaisPróximoaoClientecomDomain...
SegundooDDD,éessemodeloqueosdesenvolvedoresvãoimplemen-
taremcódigo. Literalmente. Item por item, como foi acordado por todos.
Será desenvolvido um código limpo, com palavras do domínio, que repre-
senta,naprogramação,odomínioemdiscussão.
UsandoDDD,seuprogramaorientadoaobjetosdeveexpressarariqueza
do domain model. Qualquer mudança no modelo (e, acredite, isso é muito
comum) deve ser refletida imediatamente no código. Se algo do modelo
torna-seinviáveldeseimplementartecnicamente,nãosefazum“ajustezinho”
nocódigo;omodelodevesermudadoparasermaisfácildeseimplementar.
Ou seja, no DDD, sempre seu código será expressão do modelo, que,
porsuavez,ébaseadototalmentenodomínio.
1.3 Implementando o Domain Model
Escrever código elegante é um dos maiores desafios que os programadores
enfrentam. Simplesmente escrever por escrever, qualquer ferramentazinha
quegerecódigoconseguefazer.Masescreverbonscódigos,legíveis,flexíveis
ericoséorealdesafio.
O DDD define uma série de design patterns para facilitar a implemen-
taçãodomodeloemcódigo. Comoqualquerdesignpattern,éumaidéiade
comocodificarcertosproblemascomunsdeformaelegante.
Mas,percebaqueoobjetivodeumdesignpatternéajudaroprograma-
dor! E o principal para o DDD, como vimos, é o Domain. Os patterns são,
portanto,apenasferramentasquefacilitamaimplementaçãodoDomainMo-
delnocódigo. Mas,comabsolutacerteza,essenãoéopontoprincipaldo
DDD.
Observocomfreqüênciainfindáveisdiscussõesemtornodepatternsdo
DDD,ondesurgemreceitasmágicasqueaparentementepodemseraplicadas
emqualquerprojetoepronto,temosDDD.Esseéumdosmaioreserrosque
sepodecometer.
Nãoexistereceitapronta,nãoexistecertoouerradoaoescreversuasclas-
ses. SequerusarDDD,lembre-sedoprincipal: oDomain. Vocêpodecriar
um Model riquíssimo e um código muito bem escrito; mas se ele não for
expressão do Domain, se não for a partir da língua comum, você não está
3
1.4. DDD(quase)naprática CasadoCódigo
usandoDDD.
Reparequenãosoucontrárioaospatterns,muitopelocontrário.Sãoex-
tremamenteúteisparaoprogramador,abremacabeçaparasoluçõesquenor-
malmentenosatormentamecriamumapadronizaçãonasferramentasdodia
adiadodesenvolvedor.CriticoaquiquemencaraoDDDcomoumconjunto
depatterns.Nãoé,eestálongedisso.
1.4 DDD (quase) na prática
Domain-DrivenDesignéentãosobreoDomain.Sobretodosconversarema
respeitododomínio.Sobreacriaçãodeumalínguacomumentredesenvolve-
doreseespecialistasdedomínio.Então,parausarDDD,temosqueconversar
muito!Calma,caroleitor,nãoofareiconversarcomarevista.Maspodemos
tentarsimularalgo.
AConversa
Imaginequesomosaequipededesenvolvedorescontratadaporalguém
interessadoemmontarumalojadepeixes.Evamostodosláconversar:
• Desenvolvedor: Boa tarde, eu sou programador Java certificado
SC#@$.
• Cliente: Boa tarde, mas não era bem isso que eu precisava... queria
alguémpradesenvolverumsistemapramim.
• Desenvolvedor: Ops,desculpe.Eusouumdesenvolvedor.Essascoisas
queeufaleisãodetalhesquenãointeressammesmo.
• Cliente: Ótimo!Bom,meunomeéMr.SellFishequeroabrirumaloja
quevendepeixesquetenhoaquinomeulago.
• Desenvolvedor: Certo...LojadePeixes...tipoumpeixe-espada?
• Cliente: Não. Peixe-espada é um triquiurídeo, de água salgada. Eu
vendopeixesdomeulago,águadoce. Tenholambaris,carpas,tamba-
quis,tilápiaseoutrosciclídeos.
4
CasadoCódigo Capítulo1. CriandoSoftwaremaisPróximoaoClientecomDomain...
• Desenvolvedor: ????
• Cliente: Deixe-me simplificar: tenho vários peixes, cada um de uma
espéciediferente.
• Desenvolvedor: Ahsim. Váriospeixes,váriasespécies,cadapeixeéde
umaespécie...Háoutrasinformaçõesimportantessobrecadapeixe?
• Cliente: Comcerteza!Aquinossospeixestêmumnomedebatismo,a
idadedeleepossuemcoresdiferentestambém.
• Desenvolvedor: Humm...vejameudesenho:
• Cliente: Interessante. OtraçosignificaqueoPeixetemumaespécie,
certo?Masqueraiosé“id”?
• Desenvolvedor: Éumcódigoúnicoqueprecisoparacadacoisanosis-
tema,coisasdacomputação.Vouchamarde“código”prafacilitarnosso
entendimento.
• Cliente: Ótimo! Vou precisar cadastrar todos os meus peixes e suas
espécies.Querofazerumalojadiferentecheiaderecursosparaocliente
encontraropeixecertopraele.
5
1.4. DDD(quase)naprática CasadoCódigo
• Desenvolvedor: Entãooclienteteráalgumasbuscasavançadas...quais
seriamimportantes?
• Cliente: Quero saber quais peixes são de uma determinada espécie
ou de uma determinada cor, buscar peixes pelo nome e talvez outras
coisas.
• Desenvolvedor: Vejamos:
• Cliente: Muito bom! Acho que estou entendendo... Mas como vou
buscarpelonomemesmo?
• Desenvolvedor: Ahsim... Bom,naverdadevocêprecisaé,dadotodos
ospeixesdisponíveis,saberquemtemdeterminadonome. Eupreciso
entãoprocuraressespeixesemalgumlugar... possochamaresselugar
deRepositóriodePeixes?
• Cliente: Repositório? Podesim... Umrepositórioentãoéondeestão
todos os peixes, certo? E, por lá, eu consigo saber qual Peixe tem tal
nome?
• Desenvolvedor: Isso!
6
