Angular 4

O que há de novo:

  • Menor e mais rápido
    • View Engine
    • Pacote de Animação
  • Novas características
    • Angular Universal
    • Compatibilidade com TypeScript 2.1 e 2.2
    • Source Maps for Templates
  • Packaging Changes

    • Flat ES Modules (Flat ESM / FESM)

    • Experimental ES2015 Builds

    • Compatibilidade de Encerramento Experimental

Menor e mais rápido

Nesta versão, foi cumprida promessa de tornar as aplicações Angulares menores e mais rápidas. De forma alguma já terminamos, e você verá mais melhorias nos próximos meses

View Engine

Alterações sob o hood para  AOT. Essas alterações reduzem o tamanho do código gerado para seus componentes em cerca de 60% na maioria dos casos. Quanto mais complexos forem seus modelos, maior será a economia.
Durante nosso período de candidatura à divulgação, ouvimos de muitos desenvolvedores que a migração para 4 reduziu seus bundles de produção em centenas de kilobytes.
Leia o Design Doc para saber mais sobre o que fizemos com o View Engine.

Pacote de Animação

Foi removido animações de @angular/core e em criamos seu próprio pacote. Isso significa que se você não usar animações, este código extra não vai acabar em seus pacotes de produção.
Esta alteração também permite que você encontre mais facilmente a documentação e aproveite melhor o preenchimento automático. Você pode adicionar animações ao seu NgModule principal importando o BrowserAnimationsModule de @angular/platform-browser/animations.

Novas características

Melhorado *ngIf e *ngFor

A sintaxe de vinculação de modelo agora suporta algumas mudanças úteis. Agora você pode usar uma sintaxe de estilo if /else e atribuir variáveis locais, como ao desenrolar um observable.

User {{i}} of {{count}}
Loading...

Loading…

Angular Universal

O Universal, o projeto que permite que os desenvolvedores executem o Angular em um servidor, agora está de novo atualizado com o Angular, e este é o primeiro lançamento desde que o Universal, originalmente um projeto dirigido pela comunidade, foi adotado pela equipe Angular.Esta versão agora inclui os resultados do trabalho interno e externo da equipe da Universal nos últimos meses. A maioria do código Universal está agora localizada em @angular/platform-server.Para saber mais sobre como tirar vantagem do Angular Universal, dê uma olhada no novo método renderModuleFactory no @angular/platform-server, ou no Demo Repository do Rob Wormald. Mais documentação e exemplos de código estão disponíveis.

Compatibilidade com TypeScript 2.1 e 2.2

Atualizamos o Angular para uma versão mais recente do TypeScript. Isso irá melhorar a velocidade do ngc e você obterá melhor tipo verificação em toda a sua aplicação.

Source Maps for Templates

Agora, quando há um erro causado por algo em um de seus modelos, geramos mapas de origem que dão um contexto significativo em termos do modelo original

 

Packaging Changes

Flat ES Modules (Flat ESM / FESM)

Agora enviamos versões comprimido de nossos módulos (versão “rolled up” do nosso código no formato EcmaScript Module, veja example file). Esse formato deve ajudar a tree-shaking, ajudar a reduzir o tamanho de seus bundles gerados e acelerar a compilação, transpilação e carregamento no navegador em determinados cenários.

Leia mais sobre a importância dos módulos Flat ES “The cost of small modules”.

Experimental ES2015 Builds

Agora também enviamos nossos pacotes no formato ES2015 Flat ESM. Esta opção é experimental e opt-in. Os desenvolvedores relataram até 7% de economia de tamanho de pacote ao combinar esses pacotes com o Rollup. Para testar esses novos pacotes, configure sua build de ferramentas de compilação para resolver a propriedade “es2015” em package.json sobre a propriedade regular “module”.

Compatibilidade de Encerramento Experimental

Todo o nosso código agora tem anotações de encerramento, tornando possível aproveitar as otimizações de fechamento avançadas, resultando em tamanhos de pacote menores e melhor tree shaking.

 

Anúncios

O que são Bounded Contexts e Context Maps em Domain Driven Design?

O que são Bounded Contexts e Context Maps em Domain Driven Design?

antes só gostaria de deixar claro, este artigo como outros é tirado de sites para próprio aprendizado, talvez encontrem algum erro de tradução, quem poder ajudar melhorar o post, sinta se a vontade, o mesmo para indicar artigos, sempre deixarei a fonte no fim da pagina.

Vamos estar olhando para duas partes do Domain Driven Design, em terminologia bounded contexts e context Maps.

Qual é o modelo de domínio (domain model)?

O Modelo de Domínio é o conhecimento com estruturado que está relacionada a um problema específico. O modelo de domínio em si poderia ser um código, a prosa escrito ou um diagrama, o próprio meio não é realmente importante.

O modelo de domínio centra a sua atenção sobre um problema específico. Esta restrição obriga a realmente chegar ao coração do problema sem ter em conta tudo, desde o mundo exterior.

Isso significa que o modelo de domínio terá a sua própria linguagem interna que representa as coisas importantes que são específicos para um problema.

Se você é iniciando seus estudo em  em  Modelo de Domínio, eu recomendo que você leia pós da semana passada , antes de continuar com esta.

O mundo real dos modelos de domínio coexistindo

A ideia teórica de um modelo de domínio faz muito sentido no mundo da programação. Um modelo de domínio é o conhecimento focalizado de um problema e assim ter uma descrição clara do problema e da solução torna a sua vida como um programador muito mais fácil.

Ter um único modelo é um objetivo nobre, porque um único modelo unificado é, em teoria, mais fácil de obter a sua cabeça em torno.

No entanto, no mundo real da construção de aplicativos para empresas, nunca há apenas um único modelo de domínio. Se você está construindo uma aplicação que toca muitas partes de uma empresa já existente, você provavelmente vai encontrar vários modelos de domínio coexistindo que muitas vezes se contradizem uns aos outros.

Por exemplo, em uma aplicação web típica de comércio eletrônico, o termoproduto provavelmente vai significar algo diferente no sistema de estoque do que no sistema de catálogo. Isso pode significar que os dois sistemas diferentes têm duas idéias diferentes de responsabilidade por esse objeto, ou que o objeto deve ter dois jogos completamente diferentes dos recursos.

Quando os objetos têm várias responsabilidades diferentes para diferentes partes de um aplicativo que pode se tornar monolítica e difícil de trabalhar. O que é mais, quando há vários desenvolvedores trabalhando em problemas diferentes usando os mesmos objetos, inevitavelmente haverá requisitos e a introdução de erros e inconsistências imprevistas conflitantes.

Um modelo de domínio deve ser o conhecimento centrada em torno de um problema particular. Isto limita o âmbito do modelo de domínio de um contexto muito específico. Quando se deparar inevitavelmente essas idéias conflitantes, é hora de dar um passo atrás do Modelo de Domínio.

O que é um Contexto Limitada?

Um Contexto Limitada é a fronteira que envolve um modelo particular. Isso mantém o conhecimento dentro do limite consistente, enquanto ignorando o ruído do mundo exterior.

Isto é benéfico para um número de razões.

Em primeiro lugar você pode modelar os aspectos do problema sem ter que se preocupar com outras partes do negócio. Usando o exemplo anterior, umproduto objeto dentro do sistema de estoque só precisa se preocupar com os métodos e propriedades desse sistema único, em vez de qualquer outra preocupação das empresas que acontece para caber em um objeto chamado de produto .

Em segundo lugar a terminologia dentro de um contexto Limitada pode ter uma definição única, claro que descrevem com precisão o problema na mão.Diferentes departamentos através de uma empresa geralmente tem um pouco diferentes ideias e definições de termos semelhantes, mas muitas vezes isso pode inviabilizar um projeto através de uma falta de clareza e compreensão quando os termos são misturados.

O que é um Contexto do Mapa (Context Maps)?

Quando você começar a pensar sobre os vários subsistemas de um aplicativo como indivíduo Bounded Contextos, você pode perder de vista a visão global do negócio como um todo.

É inevitável que os vários contextos delimitadas de um aplicativo precisa para se comunicar ou compartilhar dados entre si.

Um mapa de contexto é a visão global da aplicação como um todo. Cada contexto Delimitada se encaixa dentro do mapa de contexto para mostrar como eles devem se comunicar entre si e como os dados devem ser compartilhados.

Conclusão

Contexto limitada são uma ferramenta de modelagem muito importante quando se trata de Domínio Driven Development.

Contextos delimitadas permitem dividir um grande problema em problemas muito menores para que você possa se concentrar em aspectos específicos do aplicativo sem ter em conta tudo o resto.

Isto permite-lhe formar uma linguagem consistente em torno desse problema específico para que todos tenham uma definição clara de cada um dos termos importantes.

Normalmente haverá alguns objetos em uma aplicação web que têm definições diferentes em contextos diferentes do aplicativo. Ao dividir a aplicação em contexto Delimitada, você garante que as linhas entre cada contexto são claramente definidos para que a terminologia em torno de idéias e conceitos da aplicação são claramente compreendido.

No entanto, quando você se concentrar em minúcias, muitas vezes você pode perder de vista o quadro maior da aplicação. Um mapa de contexto deve mostrar onde cada Contexto Bounded senta-se em relação aos outros. Há muitas vezes uma grande quantidade de informações importantes das associações de Bounded Contextos e então um mapa de contexto garante que o conhecimento não cair através das lacunas.

fonte: http://culttt.com/2014/11/19/bounded-contexts-context-maps-domain-driven-design/