Visando uma melhor modularização, o Demoiselle está dividido por funcionalidades. Isto significa que o framework não é monolítico, no qual todas as suas funcionalidades estão contidas em um único pacote. Aliás, esta estratégia não é a mais indicada, pois projetos com um propósito específico, que não necessitam de persistência ou interface Web, por exemplo, teriam dependências desnecessárias. Assim, o Demoiselle é separado em Core, Extensões e Componentes. O Core do Demoiselle contém aquelas funcionalidades comuns a todas as extensões e aplicações. O core é simples, leve e formado majoritariamente por interfaces e poucas implementações. O Core é a base do framework, sem ele, as extensões e a própria aplicação não funcionariam. As Extensões, como o próprio nome sugere, estendem o Core com funcionalidades extras e bem específicas a um domínio ou tecnologia. Neste contexto, caso sua aplicação necessite de persistência com JPA, o framework fornecerá facilidades para você; contudo, estas funcionalidades não estão no Core. Para este propósito existem as extensões como a demoiselle-jpa, por exemplo. Cabe destacar que as extensões não possuem vida própria, pois estão diretamente ligadas ao núcleo do framework, inclusive o ciclo de vida das extensões está totalmente acoplado ao do Core. Já os Componentes são artefatos separados e que, portanto, não são dependentes diretamente do Core. Aliás, os Componentes podem até mesmo existir sem referenciar o Core. Desta forma, o seu ciclo de vida é totalmente independente do Core e Extensões. Um componente não precisa, necessariamente, estender o comportamento do Core, mas permitir disponibilizar novas funcionalidades ao usuário. Outra diferença importante é que, diferente de Core e Extensões, os Componentes não necessariamente são aderentes a alguma especificação. Um exemplo é o demoiselle-validation.

As boas práticas de programação nos alertam para que nunca sejamos dependentes de implementações, mas sempre de interfaces ou, como alguns costumam dizer, depender de contratos. Portanto a sua aplicação precisará apenas depender das interfaces que o Demoiselle provê. As implementações específicas e internas do Framework serão injetadas automaticamente pelo CDI. As classes do pacote internal nunca devem ser referenciadas pela sua aplicação! Qual o motivo de toda esta explicação? Os programadores mais curiosos irão encontrar classes do framework que estão inseridas no pacote br.gov.frameworkdemoiselle.internal. As classes deste pacote não devem ser usadas diretamente pela sua aplicação, caso contrário você estará acoplando-a com a implementação interna do Framework. A equipe do Demoiselle possui atenção especial quanto às suas interfaces (contratos) e não irá modificá-las sem antes tornar públicas as mudanças. Contudo, tudo que consta no pacote br.gov.frameworkdemoiselle.internal pode sofrer mudanças repentinas. Se você referenciar tais classes internas, a sua aplicação pode deixar de funcionar ao atualizar a versão do Demoiselle.

É importante reforçar que o Demoiselle não obriga nenhum tipo de arquitetura para as aplicações, que podem ser constituídas por quantas camadas forem necessárias. Contudo, é prudente não exagerar! Para quem não sabe por onde começar, sugerimos uma arquitetura e padrões largamente utilizados pelo mercado, de forma a facilitar a manutenção e para melhor modularização de seu projeto. Usualmente, as aplicações são constituídas por pelo menos três camadas, desta forma é comum separar as lógicas de apresentação, regras de negócio e persistência. O Demoiselle já fornece estereótipos que visam tornar esta separação mais clara, respectivamente: @ViewController, @BusinessController e @PersistenceController. Maiores detalhes sobre cada anotação serão dados no decorrer desta documentação. Cabe destacar que estamos falando de uma macro-visão arquitetural. Cada camada pode ser organizada internamente da melhor forma possível, ou conforme os padrões vigentes no mercado. Para uma aplicação Swing, por exemplo, o padrão de projeto Presentation Model é bastante indicado. Para aplicações Web, os frameworks especialistas geralmente aplicam o padrão MVC (Model/View/Controller).