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. 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. As interfaces existem para isto: definem um contrato, enquanto as implementações deste contrato ficam à parte, de preferência, distante do programador da aplicação. O mecanismo de injeção de dependência fortalece ainda mais esta idéia. Sua aplicação precisará apenas depender das interfaces que o Demoiselle provê. A implementação específica será injetada 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 internal. Cabe alertar que as classes aí contidas não devem ser usadas diretamente pela aplicação, caso contrário, você estará acoplando-a com a implementação interna do framework, que pode sofrer mudanças sem aviso prévio. 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 internal pode sofrer mudanças repentinas. Isto significa que sua aplicação pode deixar de funcionar de uma versão para outra caso você esteja usando diretamente classes internas.

É importante reforçar que o Demoiselle não obriga nenhum tipo de arquitetura para as aplicações, que podem ser constituídas com 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 com 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 desta serão dados no decorrer desta documentação. Cabe destacar que estamos falando de uma macro-visão arquitetural. Cada camada desta 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 e pode ser adotado em aplicações nesta plataforma. Para aplicações Web, os frameworks especialistas geralmente aplicam o padrão MVC (Model/View/Controller).