I

Colocando o modelo de domnios em ao

Este mapa chins do sculo 18 representa o mundo todo. No centro, e ocupando a maior parte do espao, est a China, cercada por representaes espalhadas de outros pases. Este um modelo do mundo adequado quela sociedade, que intencionalmente havia sido fechada. A viso de mundo que o mapa representa no deve ter ajudado a lidar com estrangeiros. Certamente, ela no se aplicaria China moderna. Mapas so modelos, e cada modelo representa algum aspecto da realidade com uma idia que seja de interesse. Um modelo uma simplificao. Ele uma interpretao da realidade que destaca os aspectos relevantes para resolver o problema que se tem em mos ignorando os detalhes estranhos. Cadaprogramadesoftwareestrelacionadoaalgumaatividadeouinteressedo seu usurio. Essa rea de assunto em que o usurio aplica o programa o domnio do software. Alguns domnios envolvem o mundo fsico: o domnio de um programa de reservas de passagens areas envolve pessoas reais entrando em aeronaves reais. Alguns domnios so intangveis: o domnio de um programa de contabilidade so o dinheiro e as finanas. Os domnios dos softwares geralmente tm pouco a ver com computadores, embora haja excees: o domnio de um sistema de controle de cdigos-fonte o prprio desenvolvimento de softwares. Para criar softwares que tenham valor para as atividades desempenhadas pelos usurios, a equipe de desenvolvimento deve trazer consigo um conjunto de conhecimentos relacionados a essas atividades. A quantidade de conhecimento necessria pode ser estarrecedora. O volume e a complexidade de informaes podem ser imensos. Modelos so ferramentas para atacar essa sobrecarga. Um modelo uma forma de conhecimento seletivamente simplificada e conscien2
pa rt e I

temente estruturada. Um modelo adequado faz com que as informaes tenham sentido e se concentra em um problema. Um modelo de domnio no um diagrama especfico; ele a idia que o diagrama pretende transmitir. Ele no simplesmente o conhecimento existente na cabea de um especialista em domnios; ele uma abstrao rigorosamente organizada e seletiva daquele conhecimento. Um diagrama pode representar e comunicar um modelo, assim como acontece com um cdigo cuidadosamente escrito, assim como uma frase em portugus. A modelagem de domnios no uma questo de se criar um modelo o mais realista possvel. Mesmo em um domnio de coisas tangveis da vida real, nosso modelo uma criao artificial. Ele tambm no simplesmente a construo de um mecanismo de software que fornece os resultados necessrios. Ele mais se assemelha ao processo de criao de um filme, representando livremente a realidade com uma determinada finalidade. At mesmo um filme-documentrio no mostra uma vida real indita. Assim como um cineasta seleciona aspectos da experincia e os apresenta de forma idiossincrtica para contar uma histria ou se fazer entender, um modelador de domnios escolhe um modelo em particular pela sua utilidade.

A utilidade de um modelo no Domain-Driven Design

No DDD (domain-driven design), so trs as utilidades bsicas que determinam a escolha de um modelo. 1. O modelo e o corao do design do forma um ao outro. essa ligao ntima entre o modelo e a implementao que torna o modelo relevante e garante que a anlise a ele dedicada se aplique ao produto final, um programa de execuo. Essa ligao de modelo e implementao tambm ajuda durante a manuteno e contnuo desenvolvimento, pois o cdigo pode ser interpretado com base na compreenso do modelo. (Veja o Captulo 3). 2. O modelo a espinha dorsal de uma linguagem utilizada por todos os membros da equipe. Devido ligao de modelo e implementao, os desenvolvedores podem conversar sobre o programa nessa linguagem. Eles podem comunicar-secomosespecialistasdodomniosemanecessidadedetraduo. E como a linguagem baseada no modelo, nossa capacidade lingstica natural pode ser usada para refinar o prprio modelo. (Veja o Captulo 2). 3. O modelo um conhecimento destilado. O modelo a forma aceita pela equipe de estruturar o conhecimento do domnio e distinguir os elementos de maior interesse. Um modelo capta a forma que escolhemos para pensar no domnio medida que selecionamos termos, interpretamos conceitos e
ColoC a ndo o modelo de domnIos em a o

os relacionamos. Alinguagemcompartilhadapermitequeosdesenvolvedores e os especialistas do domnio trabalhem efetivamente em conjunto medida que colocam informaes nessa forma. A ligao de modelo e implementao faz com que as experincias obtidas com verses anteriores do software sejam aplicveis como feedback para o processo de modelagem. (Veja o Captulo 1). Os trs prximos captulos examinam o significado e o valor de cada uma dessas contribuies, uma de cada vez, e como elas esto interligadas. O uso de um modelo dessa forma pode sustentar o desenvolvimento do software com grandes funcionalidades que, de outra forma, precisariam de investimentos macios de desenvolvimento na medida dos acontecimentos.

O corao do software
O corao do software est na sua capacidade de resolver problemas relacionados ao domnio para o seu usurio. Todas as outras caractersticas, por mais vitais que possam ser, se apiam nessa finalidade bsica. Quando o domnio complexo, esta uma tarefa difcil, exigindo a concentrao de esforos de pessoas talentosas e capacitadas. Os desenvolvedores tm que mergulhar a fundo no domnio para adquirir conhecimentos sobre o negcio. preciso afiar sua capacidade de modelagem e dominar design de domnios. Todavia, estas no so as prioridades na maioria dos projetos de software. A maioria dos desenvolvedores talentosos no tem muito interesse em aprender sobre um domnio especfico em que eles estejam trabalhando, muito menos firmar um compromisso em expandir suas capacidades de modelagem de domnios. Pessoas tcnicas gostam de problemas quantificveis que exercitem suas capacidades tcnicas. O trabalho com domnios confuso e exige muitos novos conhecimentos complicados que parecem no acrescentar nada capacidade de um cientista da computao. Em vez disso, o talento tcnico direcionado para o trabalho com estruturas elaboradas, na tentativa de resolver problemas relacionados a domnios usando a tecnologia. Aprender e modelar domnios ficam a cargo dos outros. A complexidade existente no corao de um software deve ser enfrentada cara a cara. Qualquer tentativa de se fazer o contrrio arriscar a irrelevncia. Em uma entrevista dada a um programa deTV, o humorista John Cleese contou umahistriadeumeventoqueaconteceuduranteafilmagemdeMontyPythonand the Holy Grail (Monty Pyhton em busca do clice sagrado). Eles j haviam filmado uma determinada cena vrias vezes, mas, de alguma forma, ela no era engraada. Finalmente, ele fez uma pausa e consultou um amigo comediante, Michael Palin (o

pa rt e I

outroatordacena),efizeramumapequenavariao.Foifilmadomaisumatomada, que dessa vez ficou engraado, e eles deram o dia por encerrado. No dia seguinte, Cleese estava dando uma olhada no rascunho que o editor do filme havia feito sobre o trabalho do dia anterior. Ao chegar cena com a qual eles haviam lutado vrias vezes, Cleese no achou nada engraado; fora usada uma das tomadas anteriores. Ele ento perguntou ao editor do filme porque no havia sido usada a ltima tomada, conforme as instrues. No pude us-la. Algum entrou e apareceu na cena, respondeu o editor. Cleese assistiu cena vrias vezes, mas no conseguiu ver nada de errado. Finalmente, o editor pausou o filme e apontou para a manga de um casaco visvel por alguns instantes no canto da imagem. Oeditordofilmeestavaconcentradonaperfeitaexecuodesuaespecialidade. Estava preocupado que outros editores que assistissem a seu filme julgassem seu trabalho com base em sua perfeio tcnica. No processo, o corao da cena havia sido perdido (The Late Late Show with Craig Kilborn, CBS, setembro de 2001). Felizmente, a cena engraada foi restaurada por um diretor que entendia de comdia. Exatamente da mesma forma, os lderes de uma equipe que entendem os fundamentos de um domnio podem colocar seu projeto de software de volta em seu rumo quando o desenvolvimento de um modelo que reflete um profundo entendimento se perde em meio confuso. Este livro mostra que o desenvolvimento de domnios traz oportunidades para cultivar capacidades bastante sofisticadas de design. A confuso da maioria dos domnios de software , na verdade, um interessante desafio tcnico. De fato, em vrias disciplinas cientficas, complexidade um dos tpicos atuais mais motivantes, pois os pesquisadores tentam controlar a confuso da vida real. Um desenvolvedor de software tem essa mesma perspectiva quando se depara com um domnio complicado e que nunca foi formalizado. Criar um modelo lcido que elimine essa complexidade algo excitante. Existem maneiras sistemticas de pensar que podem ser empregadas pelos desenvolvedores na busca por novas vises e pela gerao de modelos eficazes. Existem tcnicas de design que podem dar ordem a um aplicativo de software em expanso. O cultivo dessas capacidades torna um desenvolvedor muito mais valioso, at mesmo em um domnio inicialmente pouco familiar.

ColoC a ndo o modelo de domnIos em a o

um

Assimilando o conhecimento

lguns anos atrs, decidi criar uma ferramenta de software especializada para o projeto de uma placa de circuito impresso (PCI). Uma armadilha: no sabia nada sobre hardware eletrnico. Obviamente, tive acesso a alguns projetistas de PCIs, mas, normalmente, bastavam 3 minutos para que eles deixassem minha cabea pegando fogo. Como que eu poderia conseguir entender o suficiente sobre o assunto para escrever esse software? Certamente, eu no ia me tornar um engenheiro eletricista antes do prazo de entrega do servio! Tentamos fazer com que os projetistas de PCIs me dissessem exatamente o que o software deveria fazer. Pssima idia. Eles eram timos projetistas de circuitos, mas suas idias sobre softwares geralmente envolviam a leitura de um arquivo ASCII, sua classificao, sua escrita com algumas anotaes e a gerao de um relatrio. Isso obviamente no levaria ao grande avano em produtividade que eles procuravam. Osprimeirosencontrosforamdesmotivantes,mashaviaumsinaldeesperana nos relatrios que eles pediram. Eles sempre envolviamredese vrios detalhes sobre elas. Uma rede, nesse domnio, essencialmente um condutor de fios que podeconectar qualquer nmero de componentesdeumaPCIetransmitirumsinal eltrico a tudo a que ele esteja conectado.Tnhamos ento o primeiro elemento do modelo do domnio.

Figura 1.1

Comeceiadesenhardiagramasparaelesdeacordocomoqueelesqueriamque osoftwarefizesse.Useiumavarianteinformaldediagramasdeinteraodeobjetos para traar os cenrios.

Figura 1.2

Especialista em PCI 1: Os componentes no teriam que ser chips. Desenvolvedor (eu): Ento eu deveria cham-los apenas de componentes? Especialista 1: Ns o chamamos de instncias de componentes. Pode haver vrios componentes do mesmo tipo. Especialista 2: A caixa daredeparece ser exatamente uma instncia de componente. Especialista 1: Ele no est usando a nossa notao. Para eles, tudo uma caixa, suponho. Desenvolvedor: Confesso que sim. Acho melhor eu explicar essa notao um pouco mais. Eles me corrigiam constantemente, e medida que o faziam, comecei a aprender.Eliminamoscoliseseambigidadesemsuasterminologiaseasdiferenasentre suas opinies tcnicas, e eles aprenderam. Comearam a explicar as coisas com mais preciso e consistncia, e comeamos a desenvolver um modelo juntos. Especialista 1: No basta dizer que um sinal chega a um ref-des, temos que saber qual pino. Desenvolvedor: Ref-des? Especialista 2: O mesmo que instncia de componentes. Ref-des o nome usado em uma ferramenta que utilizamos. Especialista 1: De qualquer forma, uma rede conecta um determinado pino de uma instncia a um determinado pino de outra. Desenvolvedor: Quer dizer ento que um pino pertence a apenas uma instncia de componentes e se conecta a apenas uma rede? Especialista 1: Sim, exatamente.
8
C a p t u l o 1: a ssI m I l a n do o Con h eC I m e n to

Especialista 2: Alm disso, cada rede tem uma topologia, um arranjo que determina a forma em que os elementos da rede se conectam. Desenvolvedor: OK, que tal isso?

Figura 1.3

Para enfocar nossa explorao, limitamo-nos, por um tempo, a estudar um recursoespecfico.Umasimulaodetesterastreariaapropagaodeumsinalpara detectar possveis locais de certos tipos de problemas no projeto. Desenvolvedor: Entendo como o sinal transmitido pela Rede a todos os Pinos ligados, mas como que ele vai alm disso? Ser que a Topologia tem algo a ver com isso? Especialista 2: No. O componente empurra o sinal. Desenvolvedor:Certamente no podemosmodelarocomportamentointernode um chip. Seria muito complicado. Especialista 2: No necessrio. Podemos usar uma simplificao. Apenas uma lista de empurres dados atravs do componente de certos Pinos para certos Pinos. Desenvolvedor: Algo mais ou menos assim? [Com considerveis tentativas e erros, juntos esboamos um cenrio].

Figura 1.4
C a p t u l o 1: a ssI m I l a n do o Con h eC I m e n to

Desenvolvedor: Mas o que exatamente voc precisa saber com base nessa computao? Especialista 2: Estamos interessados nos atrasos prolongados de sinal por exemplo, qualquer trajeto de sinais que tenha sido mais do que dois ou trs pulsos. uma regra prtica. Se o trajeto for muito longo, o sinal pode no chegar durante o ciclo do relgio. Desenvolvedor: Mais do que trs pulsos... Ento precisamos calcular a extenso dos trajetos. E o que conta como sendo um pulso? Especialista 2: Cada vez que o sinal passa por uma Rede, um pulso. Desenvolvedor: Ento poderamos prolongar o nmero de pulsos, e uma Rede poderia increment-lo, da seguinte forma:

Figura 1.5

Desenvolvedor: A nica parte que no ficou clara para mim de onde vm os empurres. Esses dados so armazenados para cada Instncia de componente? Especialista 2: Os empurres seriam os mesmos para todas as instncias de componente. Desenvolvedor: Ento o tipo de componente determina os empurres. Eles seriam os mesmos para cada instncia?

Figura 1.6

10

C a p t u l o 1: a ssI m I l a n do o Con h eC I m e n to

Especialista 2: No sei exatamente o que significa cada uma das partes, mas imaginoqueoarmazenamentodeempurresdecadacomponenteteriaumaspecto parecido com isso. Desenvolvedor: Desculpe.Coloqueidetalhesdemais.Estavaspensando...Agora, ento, onde entra a Topologia? Especialista 1: Ela no usada para a simulao de teste. Desenvolvedor: Ento vou deix-la de fora por enquanto, OK? Podemos traz-la de volta quando chegarmos a essas caractersticas. E assim as coisas caminharam (com muito mais tropees do que mostrados aqui). Colhendo e refinando idias, questionando e explicando, o modelo se desenvolveu junto com o meu entendimento do domnio e o entendimento que eles tinham de como o modelo atuaria na soluo. Um diagrama de classes para representar o modelo inicial tem a seguinte aspecto:

Figura 1.7

Depoisdemaisalgunsdias,percebiqueentendiaosuficienteparatentaralgum tipodecdigo.Escreviumprottipobastantesimples,movidoporumaestruturade testeautomatizada.Eviteitodaainfra-estrutura.Nohavianenhumapersistnciae nenhuma interface com o usurio (IU). Isso me permitiu concentrar no comportamento. Consegui demonstrar uma simulao de teste simples em poucos dias. Emborautilizassedadosfictcioseescrevessetextopuronoconsole,elaestavafazendoa computaorealdasextensesdetrajetosutilizandoobjetosJava.EssesobjetosJava refletiam um modelo compartilhado pelos especialistas do domnio e eu. A solidificao desse prottipo tornou mais claro para os especialistas do domnio o que o modelo significava e que relao havia entre ele e o software operacional. A partir deste ponto, as discusses sobre o nosso modelo se tornaram mais interativas,poiselespuderamvercomoincorporeimeurecm-adquiridoconhecimento no modelo e, depois, no software. E eles tiveram um feedback concreto a partir do prottipo para avaliar seus prprios pensamentos.
C a p t u l o 1: a ssI m I l a n do o Con h eC I m e n to

11

Embutidonaquelemodelo,quenaturalmentesetornoumuitomaiscomplicado do que o mostrado aqui, estava o conhecimento sobre o domnio de PCIs relevante para os problemas que estvamos resolvendo. Ele consolidou muitos sinnimos e pequenas variaes de descrio. E excluiu centenas de fatos que os engenheiros entendiam, mas que no eram diretamente relevantes, tais como os verdadeiros recursos digitais dos componentes. Um especialista em software como eu poderia observar os diagramas e, em questo de minutos, comear a entender do que se tratava o software, pois ele teria uma estrutura para organizar novas informaes e aprender com maior rapidez, para fazer dedues melhores sobre o que era importante ou no, e comunicar-se melhor com os engenheiros de PCIs. medidaqueosengenheirosdescreviamosnovosrecursosdequeprecisavam,fiz comqueelesmeconduzissematravsdoscenriosdeinteraodosobjetos.Quando os objetos do modelo no nos podiam conduzir atravs de um cenrio importante, idealizvamosnovoscenriosouosaltervamos,assimilandooconhecimento.Refinamosomodelo;ocdigoevoluiu.Algunsmesesmaistarde,osengenheirosdePCIs contavam com uma excelente ferramenta que excedia suas expectativas.

Os ingredientes de uma modelagem eficaz

Algumas coisas que fizemos levaram ao sucesso que acabei de descrever. 1. Ligando o modelo e a implementao. Esse prottipo rudimentar forjou o elo essencial logo no incio, e ele foi mantido em todas as iteraes posteriores. 2. Cultivando uma linguagem baseada no modelo. Inicialmente, os engenheiros tiveram que me explicar questes elementares sobre PCIs, e tive que explicar o que significavam diagramas de classes. Mas medida que o projeto avanava, qualquerumdenspodiatirarostermosdiretamentedomodelo,organiz-los em frases consistentes com a estrutura do modelo e ser entendido sem ambigidades e sem traduo. 3.Desenvolvendoummodeloricoemconhecimento.Osobjetostinhamumcomportamentoeimpunhamregras.Omodelonoerasimplesmenteumesquema de dados; ele era necessrio e importante para a resoluo de um problema complexo. E captava vrios tipos de conhecimento. 4. Destilando o modelo. Conceitos importantes foram acrescentados ao modelo medida que ele se tornava mais completo, mas conceitos igualmente importantesforameliminadosquandoprovavamserinteisousecundrios.Quando umconceitodesnecessrioestavaligadoaumconceitonecessrio,achava-seum novomodeloquedistinguisseoconceitoessencialparaqueooutropudesseser eliminado.
12
C a p t u l o 1: a ssI m I l a n do o Con h eC I m e n to

5. Colhendo idias e experimentando. A linguagem, aliada a esboos e uma atitude de gerao de idias, transformou nossas discusses em laboratrios do modelo, em que centenas de variaes experimentais podiam ser exercitadas, tentadasejulgadas.medidaqueaequipepassavaporcenrios,asexpresses faladasproporcionavamumrpidotestedeviabilidadedeummodeloproposto, pois o ouvido podia rapidamente detectar a clareza e a facilidade ou a estranheza da expresso. a criatividade das idias e da experimentao macia, alavancadas atravs de umalinguagembaseadaemmodelosedisciplinadapelociclodefeedbackatravs da implementao, que possibilita encontrar um modelo rico em conhecimento e destil-lo. Esse tipo de assimilao do conhecimento transforma o conhecimento da equipe em modelos valiosos.

Assimilando o conhecimento
Analistas financeiros digerem nmeros. Eles analisam centenas de nmeros detalhadamente, combinando e recombinando-os procurando pelo significado que existe por trs, em busca de uma apresentao simples que destaque o que realmente importante um entendimento que pode ser a base de uma deciso financeira. Modeladoresdedomnioeficazesdigeremconhecimento.Elestomamumatorrentedeinformaesesaemembuscadaquiloquerelevante.Experimentamuma idiadeorganizaoapsaoutra,buscandoavisosimplesquedsentidomassa. Muitos modelos so tentados, rejeitados ou transformados. O sucesso vem em um conjunto emergente de conceitos abstratos e que d sentido a todos os detalhes. Essadestilaoumaexpressorigorosadoconhecimentoespecficoconsiderado mais relevante. A assimilao do conhecimento no uma atividade solidria. Uma equipe de desenvolvedores e especialistas do domnio trabalha em conjunto, normalmente sobocomandodedesenvolvedores.Juntos,elescoletaminformaeseasdigerem dando-lhes uma forma til. O material puro vem das mentes dos especialistas do domnio, de usurios de sistemas existentes, de experincias anteriores da equipe tcnica com um sistema legado relacionado a ele ou de outro projeto no mesmo domnio. Ele vem na forma de documentos escritos para o projeto ou utilizados no negcio, e muitas, muitas conversas. As verses iniciais, ou prottipos, do retorno das experincias para a equipe e mudam as interpretaes. Noantigomtododacascata,osespecialistasdeumnegcioconversamcomos analistas,eosanalistasdigerem,assimilamepassamoresultadoparaosprogramadores, que codificam o software. Essa abordagem falha porque lhe falta feedback. Os analistas tm responsabilidade total por criar o modelo, baseados somente nas

assImIl ando o ConheCImento

13

informaes fornecidas pelos especialistas daquele negcio. Eles no tm a oportunidadedeaprendercomosprogramadoresouadquirirexperinciacomverses iniciais do software. O conhecimento escoa em uma direo, mas no acumula. Outros projetos utilizam um processo iterativo, mas deixam de acumular conhecimento porque no o assimilam. Os desenvolvedores fazem com que os especialistasdescrevamumrecursodesejadoe,emseguida,partemparaconstru-lo. Mostramaosespecialistasoresultadoeperguntamoquedevemfazeremseguida. Seosprogramadorespraticaremarefatorao,elespoderomanterosoftwarelimpo o suficiente para continuar a expandi-lo. Mas, se no estiverem interessados no domnio,osprogramadoresaprendemsomenteoqueoaplicativodevefazer,eno os princpios existentes por trs dele. Softwares teis podem ser construdos dessa forma, mas o projeto nunca chegar ao ponto em que novos recursos poderosos se revelam como corolrios aos antigos recursos. Bons programadores naturalmente vo comear a assimilar e desenvolver um modelo que possa executar mais servios. Mas, quando isso acontece somente em um ambiente tcnico, sem colaborao com especialistas do domnio, os conceitossoingnuos.Asuperficialidadedoconhecimentoproduzsoftwaresquefazem servios bsicos, mas que no contam com uma ligao profunda com a forma de pensar de um especialista naquele domnio. Ainteraoentreosmembrosdaequipemudamedidaquetodososmembros digerem aquele modelo em conjunto. O constante refinamento do modelo do domnioforaosdesenvolvedoresaaprenderosprincpiosimportantesdonegcioao qualestodandoassistncia,emvezdegerarfunesmecanicamente.Osespecialistasdodomnio geralmente refinam seuprprioentendimentosendoforadosa destilaroquesabememsuaessnciaepassamaentenderorigorconceitualexigido pelos projetos de software. Tudo isso faz com que os membros da equipe sejam mais competentes ao digerir o conhecimento. Eles eliminam aquilo que estranho. E do uma forma cada vez mais til ao modelo. Como analistas e programadores esto contribuindo para ele, ele se torna limpo, organizado e assimilado, para que possa servir de alavanca paraaimplementao.Comoosespecialistasnaqueledomnioestocontribuindo para ele, o modelo reflete um profundo conhecimento do negcio. As abstraes so princpios reais daquele negcio. medida que o modelo avana, ele se torna uma ferramenta para organizar as informaes que continuam a fluir pelo projeto. O modelo se concentra na anlise dos requisitos, interagindo intimamente com a programao e o design. E, em um crculo virtuoso, ele aprofunda a viso que os membros da equipe tm sobre o domnio, permitindo que eles vejam com mais clareza levando a um refinamento ainda maior do modelo. Esses modelos nunca so perfeitos; eles evoluem. Devem ser prticos e teis em dar sentido ao domnio. Devem ser rigorosos o suficiente para tornar o aplicativo simples de implementar e entender.
14
C a p t u l o 1: a ssI m I l a n do o Con h eC I m e n to

Aprendizado contnuo
Quando decidimos escrever um software, nunca sabemos o suficiente. O conhecimentosobreoprojetofragmentado,dispersoentremuitaspessoasedocumentos, e misturado com outras informaes de forma que nem mesmo sabemos qual conhecimentorealmentesefaznecessrio.Domniosaparentementemenosassustadorespodemenganar:nopercebemosoquantonosabemos.Essaignorncianos leva a fazer consideraes falsas. Enquanto isso, todos os projetos deixam o conhecimento escapar. As pessoas que tiverem aprendido alguma coisa continuam. A reorganizao dispersa a equipe e o conhecimento novamente fragmentado. Subsistemas fundamentais so divididos de forma que cdigos sejam produzidos, mas no conhecimento. E com as abordagens tpicas de design, cdigos e documentos no expressam de forma utilizvel esse conhecimento arduamente adquirido, e quando a tradio oral interrompida por qualquer motivo, o conhecimento se perde. Equipesaltamenteprodutivasaumentamseuconhecimentoconscientemente, praticando o aprendizado contnuo (Kerievsky 2003). Para os desenvolvedores, isso significa melhorar o conhecimento tcnico, junto com a capacidade geral de modelagemdedomnios(taiscomoasapresentadasnestelivro).Mastambminclui um aprendizado srio sobre o domnio especfico com o qual esto trabalhando. Essesmembrosautodidatasdeumaequipeformamumncleoslidodepessoasparaseconcentraremnastarefasdedesenvolvimentoqueenvolvemasreasmais crticas. (Para mais informaes sobre este assunto, veja o Captulo 15). O conhecimentoacumuladonasmentesdessaequipe-ncleofazcomqueoconhecimento seja assimilado com maior eficcia. Neste exato momento, pare e faa uma pergunta a si mesmo.Voc aprendeu algumacoisasobreoprocessodecriaodeumprojetodePCI?Emboraesteexemplo tenhasidoumtratamentosuperficialdaqueledomnio,deveriahaveralgumaprendizado quando um modelo de domnio discutido. Aprendi muito. No aprendi a ser um engenheiro de PCIs. Este no era o objetivo. Aprendi a conversar com especialistas em PCIs, entender os principais conceitos relevantes para o aplicativo e avaliar o que estvamos construindo. De fato, nossa equipe acabou descobrindo que a simulao de teste tinha uma baixaprioridadeparaodesenvolvimento,eesserecursoacabousendodescartado por completo. Com ele, foram-se partes do modelo que captavam o entendimento da transmisso de sinais atravs dos componentes e da contagem de pulsos. O fundamental do aplicativo mostrou estar em outro lugar, e o modelo mudou para trazer esses aspectos para o centro do palco. Os especialistas daquele domnio haviam aprendido mais e esclareceram melhor o objetivo do aplicativo. (O Captulo 15 discute essas questes mais a fundo). Mesmoassim,otrabalhoinicialfoiessencial.Elementosimportantssimospara o modelo foram retidos, mas o mais importante que o trabalho colocou em ao

a pr endIz a do Contnuo

15

o processo de assimilao do conhecimento que fez com que todo o trabalho posteriorfosseeficaz:oconhecimentoadquiridopelosmembrosdaequipe,desenvolvedores e especialistas do domnio; o incio de uma linguagem compartilhada; e o fechamento de um ciclo de feedback atravs da implementao. Uma viagem de descoberta tem que comear em algum lugar.

Design rico em conhecimentos

O tipo de conhecimento captado em um modelo, como o exemplo do PCI, vai alm deidentificar substantivos. As atividades e regras comerciais so to fundamentaisparaumdomnioquantoasentidadesenvolvidas;qualquerdomniotervrias categoriasdeconceitos.Aassimilaodoconhecimentogeramodelosquerefletem este tipo de viso. Em paralelo com as mudanas do modelo, os desenvolvedores fazemarefatoraodaimplementaoparaexpressaromodelo,dandoaoaplicativo uma utilizao para daquele conhecimento. com este movimento que vai alm das entidades e dos valores que a assimilao do conhecimento se torna intensa, pois pode haver inconsistncias reais entreregrascomerciais. Os especialistas dodomniogeralmentenoestocientesda complexidadedeseusprocessosmentaismedidaque,nodecorrerdeseutrabalho, elespassamportodasessasregras,reconciliamcontradiesepreenchemlacunas usando o bom senso. Um software no pode fazer isso. atravs da assimilao do conhecimentoemumtrabalhodecolaboraontimocomespecialistasemsoftware que as regras so esclarecidas, acrescentadas, reconciliadas ou descartadas.
Exemplo

Extraindo um conceito oculto

Vamos comear com um modelo de domnio bastante simples que poderia ser a base de um aplicativo para a reserva de cargas na viagem de um navio.
Voyage

Cargo

Figura 1.8

Podemosdizerquearesponsabilidadedoaplicativodereservasassociarcada Carga (Cargo) a uma Viagem (Voyage), registrando e rastreando essa relao. At a, tudo bem. Em algum lugar do cdigo do aplicativo, poderia existir um mtodo como o seguinte:
public int makeBooking(Cargo cargo, Voyage voyage) { int confirmation = orderConfirmationSequence.next(); voyage.addCargo(cargo, confirmation); return confirmation; }

16

C a p t u l o 1: a ssI m I l a n do o Con h eC I m e n to

Como sempre h cancelamentos de ltima hora, a prtica adotada no setor de transporte naval aceitar mais cargas do que uma determinada embarcao pode transportar em uma viagem. Isso recebe o nome de overbooking. svezes,usadaumasimplesporcentagemdacapacidadetotal,comoareserva de 110% da capacidade. Em outros casos, so aplicadas regras complexas, favorecendo clientes importantes ou determinados tipos de carga. Esta uma estratgica bsica no domnio do transporte naval que seria conhecidadequalquercomerciantequepertenaaestesetor,maspodenoserentendida por todo o pessoal tcnico de uma equipe de software. O documento de requisitos contm a seguinte linha: Considere 10% de overbooking. O diagrama de classes e o cdigo agora tm o seguinte aspecto:
Voyage

Figura 1.9

capacity

Cargo size

public int makeBooking(Cargo cargo, Voyage voyage) { double maxBooking = voyage.capacity() * 1.1; if ((voyage.bookedCargoSize() + cargo.size()) > maxBooking) return 1; int confirmation = orderConfirmationSequence.next(); voyage.addCargo(cargo, confirmation); return confirmation; }

Agora, uma importante regra comercial est oculta como uma clusula de proteo em um mtodo do aplicativo. Mais adiante, no Captulo 4, vamos examinar o princpio da ARQUITETURA EM CAMADAS, que nos orientar na transferncia daregradeoverbookingparaumobjetodedomnio,mas,porenquanto,vamosnos concentraremcomopoderamostornaresteconhecimentomaisexplcitoeacessvel a todos que participam do projeto. Isso nos levar a uma soluo semelhante. 1. Conforme escrito, improvvel que qualquer especialista comercial possa ler este cdigo e verificar a regra, mesmo com a ajuda de um desenvolvedor. 2. Seria difcil para uma pessoa tcnica, que no pertena rea comercial, fazer uma ligao entre o texto de requisitos e o cdigo. Se a regra fosse mais complexa, tudo isso estaria em perigo. Podemos mudar o design para melhor captar esse conhecimento. A regra do overbooking uma poltica. Poltica outro nome dado ao padro de design conhecido como ESTRATGIA (Gamma et al. 1995). Ela geralmente motivada pela necessidade de substituir regras diferentes, o que no necessrio aqui, pelo
desIgn r ICo em ConheCImentos

17

que saibamos. Mas o conceito que estamos tentando captar no se enquadra no significadodepoltica,queumamotivaoigualmenteimportantenoDDD.(Veja o Captulo 12 Relacionando padres de design com o modelo).

Figura 1.10

Agora, o cdigo fica:

public int makeBooking(Cargo cargo, Voyage voyage) { if (!overbookingPolicy.isAllowed(cargo, voyage)) return 1; int confirmation = orderConfirmationSequence.next(); voyage.addCargo(cargo, confirmation); return confirmation; }

A nova classe Poltica de overbooking contm o seguinte mtodo:

public boolean isAllowed(Cargo cargo, Voyage voyage) { return (cargo.size() + voyage.bookedCargoSize()) <= (voyage.capacity() * 1.1); }

Fica claro para todos que o overbooking uma poltica distinta, e a implementao dessa regra explcita e separada. No entanto, no estou recomendando que um design to elaborado assim seja aplicado a todos os detalhes do domnio. O Captulo 15, Destilao, vai mais a fundo em como se concentrar naquilo que importante e minimizar ou separar o restante. Este exemplo tem o objetivo de mostrar que um modelo de domnio e o designcorrespondentepodemserusadosparafirmarecompartilharconhecimento. Um design mais explcito apresenta as seguintes vantagens: 1. Para que o design chegue a esse estgio, os programadores e todas as outras pessoas envolvidas tero de entender a natureza do overbooking como uma regracomercialdistintaeimportante,enosimplesmenteumclculoobscuro. 2.Osprogramadorespodemmostraraosespecialistasdaquelenegcioartefatos tcnicos,atmesmocdigos,quedevemserinteligveisparaosespecialistasdo domnio (com um pouco de ajuda), fechando assim o ciclo de feedback.

18

C a p t u l o 1: a ssI m I l a n do o Con h eC I m e n to

Modelos profundos
Os modelos mais teis raramente ficam na superfcie. medida que comeamos aentenderodomnioeasnecessidadesdoaplicativo,geralmentedescartamoselementosdemodelossuperficiaisquepareciamimportantesnocomeo,oumudamos suaperspectiva.Surgemabstraessutisquenonosteriamocorridonoincio,mas que vo direto ao corao do problema. O exemplo anterior est baseado livremente em um dos projetos em que vou me basear para vrios exemplos dados durante o livro: um sistema de transporte de cargas em contineres. Os exemplos dados neste livro sero acessveis a especialistas que no lidam com transporte de cargas. Mas, em um projeto real, onde o aprendizado contnuo prepara os membros da equipe, os modelos de utilidade e clareza geralmente exigem sofisticao tanto no domnio quanto na tcnica de modelagem. Nesse projeto, pelo fato de o transporte comear com o ato da reserva da carga, desenvolvemos um modelo que nos permitisse descrever a carga, seu itinerrio e assim por diante.Tudo isso era necessrio e til, mas mesmo assim os especialistas do domnio se sentiam insatisfeitos. Havia uma forma em que eles enxergavam seu negcio que ainda no havamos captado. Por fim, depois de meses de assimilao de conhecimento, percebemos que o manuseiodacarga,ocarregamentoeodescarregamentofsico,osdeslocamentos de um lugar para outro, eram em grande parte realizados por subempreiteiros ou pessoal operacional da empresa. Na viso dos nossos especialistas em transporte de carga, havia uma srie de transferncias de responsabilidade entre partes. Um processogovernavaessatransfernciaderesponsabilidadelegaleprtica,dotransportador(navio)paraalgumatransportadoralocal,deumatransportadoraparaoutra, e finalmente para o consignatrio. Geralmente, a carga ficava em um armazm enquanto estavam sendo dados outros passos importantes. Outras vezes, a carga passava por etapas fsicas complexas que no eram relevantes para as decises comerciais da empresa de transporte. Em lugar da logstica do itinerrio, o que assumiaafrenteeramosdocumentoslegaistaiscomooreconhecimentodeembarque, e processos que levavam liberao de pagamentos. Essa viso mais profunda do negcio referente ao transporte de cargas no levou remoo do objeto Itinerrio, mas o modelo mudou profundamente. Nossa viso de transporte de cargas deixou de ser a movimentao de contineres de um lugar para outro e passou para a transferncia de responsabilidades pela carga de entidadeementidade.Osrecursosnecessriosparaocontroledessastransferncias deresponsabilidadejnoestavamestranhamenteligadossoperaesdecarregamento,massesustentavamporummodeloquesurgiudoentendimentodarelao significativa entre essas operaes e essas responsabilidades. Aassimilaodoconhecimentoumaexplorao,eimpossvelsaberondese pode chegar.

modelos profu ndos

19