Domain-Driven Design: (Registro n. 1320)
| 006 - Campo Fixo - Material Adicional | |
|---|---|
| fixed length control field | a|||||r|||| 00| 0 |
| 007 - Campo Fixo - Descrição Física | |
| fixed length control field | ta |
| 008 - Campo de Tamanho Fixo | |
| Campo fixo de controle local | 190617s2009 bl gr 000 0 por u |
| 020 ## - ISBN | |
| ISBN | 9788576085041 |
| 040 ## - Fonte da Catalogação | |
| Fonte de catalogação | BR-BrCADE |
| 090 ## - Número de Chamada | |
| Localização na estante | 005.1 |
| Cutter | E92d |
| 100 10 - Autor | |
| Autor | EVANS, Eric |
| 245 10 - Titulo Principal | |
| Título principal | Domain-Driven Design: |
| Subtítulo | Atacando as Complexidades / |
| 250 ## - Edição | |
| Edição | 2. ed. |
| 260 ## - Editora | |
| Cidade | Rio de Janeiro: |
| Editora | Alta Books, |
| Data | 2009. |
| 300 ## - Descrição Física | |
| Número de páginas | 499 p. |
| 505 ## - Conteúdo | |
| Conteúdo | Parte I<br/>Colocando o modelo de domínios em ação <br/>A utilidade de um modelo no Domain-Driven Design <br/>O coração do software <br/><br/>Capítulo 1:Assimilando o conhecimento <br/>Os ingredientes de uma modelagem eficaz <br/>Assimilando o conhecimento <br/>Aprendizado contínuo <br/>Design rico em conhecimentos <br/>Extraindo um conceito oculto <br/>Modelos profundo <br/><br/>Capítulo 2: Comunicação e uso da linguagem <br/>LINGUAGEM ONIPRESENTE <br/>Criando um roteador de cargas <br/>Cenário 1:Abstração mínima do domínio <br/>Cenário 2: Enriquecimento do modelo do domínio para<br/>sustentar a discussão <br/>Modelando em voz alta <br/>Uma equipe, uma linguagem <br/>Documentos e diagramas <br/>Documentos de design escritos <br/>Base executável <br/>Modelos explanatórios <br/>Operações de rotas de transporte de cargas <br/><br/>Capítulo 3: Ligando o modelo à implementação <br/>Paradigmas da modelagem e assistência às ferramentas <br/>De procedimental a DIRIGIDO POR MODELOS <br/>Design mecânico <br/>UM DESIGN DIRIGIDO POR MODELOS <br/>Mostrando tudo: por que os modelos interessam aos usuários <br/><br/><br/>Parte II<br/>Os tijolos da construção de um design baseado em modelos <br/><br/>Capítulo 4: Isolando o domínio <br/>Dividindo em camadas a funcionalidade de transações bancárias on-line <br/>Relacionando as camadas <br/>Estruturas arquitetônicas <br/>É na camada do domínio que reside o modelo <br/>Outros tipos de isolamento <br/><br/>Capítulo 5: Um modelo expresso em software <br/>Associações <br/>Modelando ENTIDADES <br/>Criando o design da operação de identidade <br/>Criando o design de OBJETOS DE VALOR <br/>Sintonizando um banco de dados com OBJETOS DE VALOR <br/>Criando designs para associações que envolvem Objetos De Valor <br/>SERVIÇOS e a camada do domínio isolada <br/>Granularidade <br/>Acesso a SERVIÇOS <br/>MÓDULOS Agile <br/>Convenções de codificação de pacotes em Java <br/>As armadilhas do empacotamento dirigido pela infraestrutura <br/>Paradigmas da modelagem <br/>Por que o paradigma do objeto predomina <br/>Não-objetos em um mundo de objetos <br/>Usando o DESIGN DIRIGIDO POR MODELOS ao misturar<br/>paradigmas <br/><br/>Capítulo 6: O ciclo de vida de um objeto do domínio <br/>Integridade de um pedido de compras <br/>Escolhendo FÁBRICAS e seus locais <br/>Quando um construtor é tudo que você precisa <br/>Criando o design da interface <br/>Onde entra a lógica das invariantes? <br/>Reconstituindo objetos armazenados <br/>Consultando um REPOSITÓRIO <br/>Os códigos do cliente ignoram a implementação do REPOSITÓRIO;<br/>mas isso não acontece com os desenvolvedores <br/>Implementando um REPOSITÓRIO <br/>Trabalhando dentro das suas estruturas <br/>A relação com as FÁBRICAS <br/>Criando objetos para bancos de dados relacionais <br/><br/>Capítulo 7: Usando a linguagem: exemplo expandido <br/>Introduzindo o sistema de transporte de cargas <br/>Isolando o domínio: introduzindo os aplicativos <br/>Distinguindo ENTIDADE e OBJETOS DE VALOR <br/>Função e outros atributos <br/>Criando associações no domínio de transporte de carga <br/>Limites dos AGREGADOS <br/>Selecionando REPOSITÓRIOS <br/>Percorrendo os cenários <br/>Amostra de um recurso do aplicativo: mudando o de tino de uma Carga Amostra de um recurso do aplicativo: negócios repetidos <br/>Criação de objetos <br/>FÁBRICAS e construtores para Carga <br/>Acrescentando um Evento de manuseio <br/>Pausa para refatoração: design alternativo do AGREGADO Carga <br/>MÓDULO no modelo do transporte de cargas<br/>Introduzindo um novo recurso: verificação de alocações <br/>Ligando o dois sistemas <br/>Aprimorando o modelo: segmentando o negócio <br/>Sintonizando o desempenho <br/>Uma última olhada <br/><br/>Parte III<br/>Refatorando em direção a uma visão mais profunda <br/><br/>Capítulo 8: Oportunidade de avanço<br/>História de uma oportunidade de avanço Um modelo decente, porém ...<br/>A oportunidade de avanço<br/>Um modelo mais profundo <br/>Uma decisão sóbria <br/>A recompensa <br/>Oportunidades <br/>Foco no básico <br/>Epílogo: uma cascata de novas visões <br/><br/>Capítulo 9: Tornando explícitos conceitos implícitos <br/>Cavando conceitos <br/>Ouça a linguagem <br/>Escutando um conceito ausente no modelo de transporte de cargas <br/>Examine minuciosamente o que há de estranho <br/>Ganhando juros pelo caminho difícil <br/>Contemple as contradições <br/>Leia o livro <br/>Ganhando juros segundo o livro <br/>Tente e tente novamente <br/>Como modelar tipos de conceitos menos óbvios <br/>Restrições explícitas <br/>Revisão: política de overbooking <br/>Processos como objetos de domínio <br/>Aplicando e implementando uma ESPECIFICAÇÃO <br/>Embalador em um depósito de produtos químicos <br/>Protótipo operacional do embalador do depósito <br/><br/>Capítulo 10: Design flexível <br/>Interfaces reveladoras de intenções <br/>Refatorando: um aplicativo para misturas de tintas <br/>Refatorando novamente o aplicativo para misturas de tintas <br/>De volta à mistura de tintas <br/>Agora podemos ver com clareza <br/>Os CONTORNOS de provisões <br/>Uma mudança não antecipada<br/>Selecionando a partir de coleções <br/>Design declarativo <br/>Linguagens específicas de um domínio <br/>Um estilo declarativo de design <br/>Estendendo ESPECIFICAÇÕES em um estilo declarativo <br/>Uma implementação alternativa da ESPECIFICAÇÃO DE<br/>COMPOSTO <br/>Ângulos de ataque<br/>Vá esculpindo os subdomínios<br/>Baseie-se em formalismos já estabelecidos, quando possível Integrando os padrões: matemática das participações <br/>Design inicial para a distribuição de pagamento<br/>Separando comandos e FUNÇÕES ISENTAS DE EFEITOS COLATERAIS<br/>Tornando explicito um conceito implícito <br/>O Bolo de participações e transforma em um OBJETO DE VALOR: <br/>Cascata de visões <br/>A flexibilidade do novo design <br/><br/>Capítulo 11: Aplicando padrões de análise <br/>Ganhando juros com contas <br/>Modelos de contabilidade em Analysis Patterns <br/>Uma nova visão sobre o lote noturno <br/>Regras de lançamento <br/>Executando as regras de lançamentos <br/>Padrões de análise são um conhecimento no qual nos devemos basear <br/><br/>Capítulo 12: Relacionando padrões depro j etos com o modelo <br/>Políticas para se achar urna rota <br/>Rota para transporte de carga formadas por rotas <br/>Por que não FLYWEIGHT? <br/><br/>Capítulo 13: Refatorando em direção a uma visão mais profunda <br/>Iniciação <br/>Equipe de exploração <br/>Arte anterior <br/>Um design para desenvolvedores Definição do tempo <br/>Crise como oportunidade <br/> <br/>Parte IV <br/>Design Estratégico <br/><br/>Capítulo 14: Mantendo a integridade do modelo <br/>Contexto de reserva de cargas <br/>Reconhecendo fragmentações dentro de um CONTEXTO DELIMITADO <br/>Dois CONTEXTOS em um aplicativo de transporte de carga <br/>Testando nos limites do CONTEXTO <br/>Organizando e documentando MAPAS DE CONTEXTO <br/>Relações entre CONTEXTOS DELIMITADOS <br/>Análise de preferência versus reservas <br/>Projetando a interface da ANTICORRUPTION LAYER <br/>Implementando a ANTICORRUPTION LAYER <br/>O aplicativo legado de reservas <br/>Uma história de cautela <br/>Um projeto de seguros é reduzido <br/>Uma LINGUAGEM PUBLICADA para química <br/>Unificando um elefante <br/>Escolhendo a estratégia de contexto do seu modelo <br/>A decisão da equipe ou superior <br/>Inserindo-nos no contexto <br/>Transformando as fronteira <br/>Aceitando aquilo que não podemos mudar: delineando os sistema<br/>externos <br/>Relações com o sistemas externos <br/>O sistema em fase de design <br/>Atendendo a necessidades especiais com modelos distintos <br/>Aplicação <br/>A compensação <br/>Quando seu projeto já está em andamento <br/>Transformações <br/>Mesclando CONTEXTOS: <br/>CAMINHOS SEPARADOS - CLEO COMPARTILHADO <br/>Mesclando CONTEXTOS: <br/>NÚCLEO COMPARTILHADO -INTEGRAÇÃO CONTÍNUA<br/>Tirando um sistema legado de circulação <br/>SERVIÇO DE HOST ABERTO -LINGUAGEM PUBLICADA <br/> <br/><br/>capítulo 15: Destilação<br/>E colhendo o NÚCLEO Quem realiza o trabalho?<br/>Escalonamento de destilações<br/>A história dos dois fusos horários Genérico não significa reutilizável Gerenciamento dos riscos de projeto O documento de destilação<br/>O NÚCLEO sinalizado<br/>O documento de destilação como ferramenta do processo Um mecanismo em um organograma<br/>SUBDOMÍNIO GENÉRICO versus MECANISMO COESIVO<br/>Quando um MECANISMO faz parte do DOMÍNIO PRINCIPAL Círculo completo: o organograma reabsorve seu MECANISMO Destilando rumo a um estilo declarativo<br/>Os custos de se criar um NÚCLEO SEGREGADO Evoluindo a decisão da equipe<br/>Segregando o NÚCLEO de um modelo para transporte de cargas Destilação de modelos profundos<br/><br/>Capítulo 16: Estrutura em larga escala<br/>A "Metáfora ingênua" e por que não precisamos dela<br/>Em profundidade: divisão de camadas de um sistema de transporte de carga<br/>Responsabilidades de "Operações" Responsabilidades de "Capacidade" Responsabilidades de 'Apoio a decisões"<br/>Como é que essa estrutura afeta o design em andamento? Escolhendo camadas adequadas<br/>Folha de pagamento de funcionários e pensão, Parte 1<br/>Folha de pagamento de funcionários e pensão, Parte 2: NÍVEL DE CONHECIMENTO<br/>A estrutura SEMATECH CIM<br/>Veja como criar um painel para a colcha<br/>Até que ponto uma estrutura deve ser restritiva? Refatorando em direção a uma estrutura adequada Minimalismo<br/>Comunicação e autodisciplina<br/>A reestruturação gera um design flexível A destilação alivia a carga<br/><br/>Capítulo 17: Unindo as peças da estratégia<br/>Combinando estruturas em larga escala e CONTEXTOS DELIMITADOS<br/>Combinando estruturas em larga escala e a destilação Avalie primeiro<br/>Quem define a estratégia?<br/>Estrutura emergente a partir do desenvolvimento do aplicativo<br/>Uma equipe de arquitetura enfocada no cliente<br/>Seis pontos essenciais para a tomada de decisões em um design estratégico<br/>O mesmo se aplica às estruturas técnicas <br/>Cuidado com o plano diretor<br/> |
| 650 #4 - ASSUNTO | |
| 9 (RLIN) | 1856 |
| Assunto | Desenvolvimento de programa |
| 650 #4 - ASSUNTO | |
| 9 (RLIN) | 1853 |
| Assunto | Administração de software |
| 650 #4 - ASSUNTO | |
| 9 (RLIN) | 1857 |
| Assunto | Linguagem de programação |
| 942 ## - Elementos de Entrada Adicionados | |
| Tipo de Material | Livros |
| 942 ## - Elementos de Entrada Adicionados | |
| Tipo de Material | Livros |
| Classificação | Empréstimo | Locação permanente | Locação corrente | Data de aquisição | Forma de aquisição | Patrimônio | Número completo de chamada | Código de barras | Número do exemplar | Data de inserção do exemplar | Tipo de item no Koha |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Biblioteca Agamenon Magalhães | Biblioteca Agamenon Magalhães | 2019-06-19 | Compra | 30008 | 005.1 E92d | 2019-0030 | 1 | 2019-06-19 | Livros |