DESENVOLVIMENTO DE UMA APLICAO PRTICA COM DDD DOMAIN

DRIVEN DESIGN, NHIBERNATE E FLUENT NHIBERNATE

Flvio Antnio da Maia Jnior
1
, Luiz Camargo
2



Resumo: O sucesso no desenvolvimento de aplicaes no est ligado apenas a resultados
finais, mas sim a tecnologias e modelos arquiteturais utilizados, os quais permitem que as
aplicaes sejam desenvolvidas com qualidade, fcil escalabilidade e manuteno, sem afetar o
resultado final e assegurando a qualidade e satisfao do aplicativo para os clientes. O presente
artigo tem como objetivo explanar o modelo criado por Eric Evans, o DDD Domain Driven
Design, no qual o foco do desenvolvimento e modelagem ligado ao domnio da aplicao
garantindo escalabilidade, fcil integrao com outras plataformas, qualidade e fcil
manuteno. Alm disso, ser feita utilizao do framework de O/RM, o NHibernate com Fluent
NHibernate para o mapeamento dos objetos e a persistncia dos dados no banco de dados
relacional; este O/RM permite que o desenvolvedor no se preocupe em como sero realizadas
as transaes da aplicao com o banco de dados, mas apenas com o domnio da aplicao onde
o repositrio realiza todas as transaes com o NHibernate, garantindo performance e que a
aplicao seja compatvel com os principais bancos de dados relacionais do mercado.

Palavras-chave: Domain-Driven Design. NHibernate. Fluent NHibernate.



1 INTRODUO

Desde o comeo das primeiras aplicaes j se preocupava com os padres arquiteturais e quais
modelagens seriam utilizadas para o desenvolvimento dos aplicativos alm de como separar as
camadas de regras de negcios das telas e repositrios.
Com a chegada das novas linguagens de programao como C-Sharp (C#) e Java, surge a
programao orientada a objetos, onde uma classe pode ser diferente de uma tabela de banco de
dados, mas pode representar todos os dados e comportamentos que a tabela representa, ou seja,
surge a separao de camadas a qual era um dilema antes do advento da programao orientada a
objetos. A partir deste momento surgiram os Object/RelationalMapping (O/RM) que permitem
aos objetos relacionais conversar com os bancos de dados relacionais disponveis no mercado.
Porm criar uma aplicao em camadas se tornou algo mais complexo do que o desenvolvimento
de aplicaes com tecnologias no qual os aplicativos eram programados de forma estrutural
atravs de procedures. Pois, agora, necessrio ir alm de se preocupar com a ideia de
desenvolver em camadas aplicando modelos arquiteturais, necessrio se preocupar com a
integridade das informaes as quais antes eram tratadas diretamente pelo prprio banco de
dados. E nesse quesito que as O/RM entram no cenrio: fazendo com que o desenvolvedor no

1
Ps-graduando em Engenharia de Software pela UNISOCIESC.
E-mail: flaviodamaiajr@gmail.com.
2
Professor nos cursos de graduao e ps-graduao na UNISOCIESC.
E-mail: camargho@gmail.com.

se preocupe em como o repositrio ir fazer as transaes com o banco de dados relacional,
sendo que as O/RM assumem essa responsabilidade, trazendo mais segurana nas transaes
garantindo a integridade das informaes entre o aplicativo e o banco de dados.
Unir esses padres, modelos e tecnologias em uma aplicao no um procedimento fcil, e
existem alguns itens a serem tratados com mais precaues para evitar o acoplamento, evitando,
assim, complexidades na hora de migrar para outro framework O/RM, por exemplo.
Neste contexto, este trabalho entra, apresentando como desenvolver uma aplicao em camadas
aplicando as premissas do modelo Domain-Driven Design (DDD) criado por Eric Evans (2009),
alm de todo o conceito de orientao a objetos para a modelagem do domnio da aplicao
juntamente com o O/RM mais utilizado no mercado para a plataforma .NET da Microsoft, o
NHibernate, o qual estabelece e assume as transaes com o banco de dados relacional em
conjunto com o FluentNHibernate, utilizado para fazer o mapeamento das classes do aplicativo
com as tabelas do banco de dados relacional.

2 ENGENHARIA DE SOFTWARE

Segundo Pressman (2011), a engenharia de software uma tecnologia dividida em camadas, que
tm como base ferramentas, mtodos e tcnicas, modelo de processo e foco na qualidade.
Podendo-se defini-la como uma aplicao de uma abordagem sistemtica, quantificvel e
disciplinada para o desenvolvimento de sistemas com qualidade, permitindo que sejam confiveis
e eficientes.
A engenharia de software surgiu com o intuito de fornecer apoio e melhorias para os processos e
mtodos, fazendo com que o software chegue com qualidade no usurio final e possa crescer de
forma escalvel sem perder a qualidade, aplicando mtodos e tcnicas para controlar as mudanas
e riscos, dando origem a modelos universais de processos de software (PETERS; PEDRYCZ,
2001).

3 DDD DOMAIN-DRIVEN DESIGN

O modelo Domain-Driven Design (DDD) a juno de princpios e prticas. Surgiu com o
intuito de diminuir as complexidades que dificultam o desenvolvimento de aplicaes, sejam elas
simples ou complexas (EVANS, 2009).
Atravs de diversos princpios e padres de projeto, o DDD visa a ajudar equipes de
desenvolvimento a entender melhor o contexto dos projetos, permitindo, assim, utilizar o
conhecimento de modelagem DDD para desenvolver um produto com mais qualidade e
satisfao aos clientes. O objetivo de utilizar a modelagem DDD em desenvolvimento de
softwares que, desta forma, o sistema construdo de dentro para fora, permitindo que as
camadas de regras de negcios sejam desenvolvidas e testadas antes de criar as outras camadas
importantes de um sistema, como interfaces e controles. A camada de interface fica separada da
camada de domnio e da infraestrutura.
De acordo com Evans (2009), um dos principais benefcios de se aplicar DDD est na
modelagem do domnio. Antigamente era comum modelar os sistemas da base de dados ao code-
behind. E, quando se trata de DDD, necessrio iniciar a modelagem a partir do domnio. no
domnio que as regras de negcios do sistema sero criadas. Elas determinam o comportamento
que o sistema dever conter.
O DDD no contm um padro definido de arquitetura, mas, segundo Evans (2009), sugerido o
modelo criado por si. Para modelar um domnio muito mais complexo, e impossvel de se fazer
simplesmente atravs de um banco de dados. Para realizar a modelagem de um domnio,
necessrio aplicar os conceitos de orientao a objetos. Com a orientao a objetos, possvel
modelar as classes contendo no s uma estrutura de dados, mas tambm modelando
comportamentos em mtodos.

A figura 1 demonstra o modelo de se aplicar o DDD, sugerido por Evans:

Figura 1 Modelo sugerido por Evans


Fonte: Evans, Eric (2009)

O modelo formado pelas seguintes camadas, apresentadas na figura 1:
Domain Layer (Camada de Domnio): Concentram-se todas as regras de negcios
existentes na aplicao;
Infraestrutura: Camada de mais baixo nvel, responsvel por prover servios como
persistncia, envio de email, criptografia de dados, ou seja, dar o suporte tecnolgico para
as demais camadas;
Application Layer (Camada de aplicao): Coordena as atividades da aplicao,
porm, no contm regras de negcio. Essa camada dependente da camada de domnio
da aplicao, onde esto as regras de negcio;
User Interface Layer (Camada de Interface do Usurio): Responsvel pela camada de
interfaces do sistema com o usurio, seja, interpretando comandos ou exibindo
informaes para o mesmo.

Quando se trata de um sistema, existe a modelagem de banco de dados relacional no qual se
criam tabelas. Aplicando o DDD, necessrio entender os conceitos de orientao a objeto para
aplicar as entidades, associaes, agregaes, factories, objetos de valor, servios e repositrios,
onde formam o modelo definido por Evans. Ou seja, assim como as tabelas relacionais esto para
um banco de dados, as entidades esto para o domnio do sistema. Qualquer tipo de objeto que
possua alguma identidade necessrio ser tratado como entidade, por exemplo, Carro. Uma
fbrica pode ter a entidade motor, onde obrigatrio que cada motor tenha um identificador
nico, conhecido como ID. Os objetos que no necessitam de identidade ou se quer mudam de
valor dentro do domnio do sistema, so modelados como objetos de valor. Os objetos de valor
normalmente so criados como ENUM, onde no se tem identidade prpria, mas possuem valores
os quais facilitam descrever o domnio do sistema e tambm permitem ser utilizados junto s
classes. Um exemplo definido por Evans um sistema bancrio, onde os bancos possuem tipos
de contas (e.g., corrente, crdito, investimento) as quais possuem valores constantes e no
possuem identidades. Segundo Evans, as entidades e objetos de valor podem se relacionar entre si
atravs de associaes, onde so modeladas na orientao a objetos e que possuem uma ligao
podendo ser agrupadas atravs de agregaes.
Com base em Evans, pode-se compreender que uma das grandes vantagens do modelo DDD
que a camada de domnio, que o corao do sistema, onde se concentra toda a regra de negcio,
e totalmente independente das outras camadas da aplicao. Caso um cliente deseja que a
aplicao seja executada na Web, desktop ou at mesmo em dispositivos mveis, no ter
problemas com as regras de negcios, pelo fato do domnio estar acoplado somente a parte de
orientao a objetos. Sendo assim, facilita a implementao do domnio em outra plataforma.

4 O/RM OBJECT/RELATIONAL MAPPING

O Object/Relational Mapping um mecanismo que faz com que seja possvel tratar, acessar e
manipular objetos sem ter a necessidade de saber como esses objetos se relacionam com suas
fontes de dados. O/RM permite que os desenvolvedores mantenham uma viso consistente dos
objetos, sem ter a necessidade de se preocupar com os bancos de dados relacionais, trabalhando
diretamente nos objetos do sistema (HIBERNATE, 2014).

4.1 NHibernate

O NHibernate uma ferramenta O/RM (objeto/relacional mapeamento) para a plataforma .NET,
a qual permite efetuar persistncia dos dados efetuando a modelagem da aplicao com as regras
de negcios quando desenvolvidas em orientao a objetos, onde se permite gravar as
informaes em banco de dados relacional. Ela uma ferramenta open source, mantida pela
comunidade do NHibernate, a NHForge. Assim como o Hibernate mantido pela comunidade do
Java (PERKINS, 2011).
O NHibernate trabalha da mesma forma que o Hibernate, com mapeamento de objetos
relacionados, onde o seu objetivo isolar os objetos permitindo a modelagem dos dados e o
controle da aplicao desenvolvida sem ter a necessidade de se preocupar em como os dados
sero armazenados ou recuperados nos bancos de dados relacionais. Sendo assim, o NHibernate
transforma os dados que esto em forma de objeto, em dados relacionais, permitindo efetuar
transaes com os bancos de dados relacionais disponveis no mercado atualmente. (LINWOD;
MINTER, 2005)

O NHibernate atualmente compatvel com os seguintes bancos de dados relacionais:
Microsoft SQL Server 2012/2008/2005/2000;
MySQL;
Oracle;
SQLite;
Microsoft Access;
Firebird;
PostgreSQL;
DB2 UDB.

Desde modo, o NHibernate permite que o desenvolvedor no se preocupe com o tipo de banco de
dados que o cliente deseja utilizar, pois o framework fica responsvel pela parte de comunicao
e transaes com o banco de dados relacional. O framework permite que o desenvolvedor crie
uma espcie de SQL para realizar consultas, so chamadas de HQL, muito similar a uma query
SQL. (PERKINS, 2011)

4.2 Fluent NHibernate

O Fluent NHibernate um framework que surgiu em 2010 por James Gregory, membro da
comunidade do NHibernate, a NHForge. Com o objetivo de facilitar e aumentar a produtividade,
foi criado um framework onde o objetivo facilitar o processo de mapeamento de objetos
relacionais. O principal objetivo que o desenvolvedor no fique perdendo muito tempo fazendo
mapeamentos via XML. O framework permite fazer os mapeamentos dos objetos via cdigo,
onde durante a compilao do projeto, o Fluent NHibernate converte o mapeamento realizado
com o framework em um arquivo XML seguido dos padres do NHibernate para mapeamento,
nomeEntidade.hbm.xml. (GREGORY, 2010)
Na figura 2, encontra-se o exemplo de como feito o mapeamento via XML, sem o Fluent
NHibernate, e a figura 3 traz um exemplo de como o mapeamento de um objeto com o Fluent
NHibernate.

Figura 2 - Exemplo de um mapeamento via XML sem o Fluent NHibernate

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
namespace="QuickStart" assembly="QuickStart">

<class name="Cat" table="Cat">
<id name="Id">
<generator class="identity" />
</id>
<property name="Name">
<column name="Name" length="16" not-null="true" />
</property>
<property name="Sex" />
<many-to-one name="Mate" />
<bag name="Kittens">
<key column="mother_id" />
<one-to-many class="Cat" />
</bag>
</class>
</hibernate-mapping>

Fonte: Fluent NHibernate (2010)
Figura 3 - Exemplo de um mapeamento via cdigo com o Fluent NHibernate

public class EmployeeMap : ClassMap<Employee>
{
public EmployeeMap()
{
Id(x => x.Id);
Map(x => x.FirstName);
Map(x => x.LastName);
References(x => x.Store);
}
}

Fonte: Fluent NHibernate (2010)

5 ESTUDO DE CASO

Neste captulo sero apresentadas as partes prticas das explanaes tericas descritas nos
captulos anteriores, as quais so necessrias para o entendimento e desenvolvimento do estudo
de caso proposto durante o perodo de delimitao do tema. Os cdigos fontes do projeto esto
disponvel no GitHub, https://github.com/flaviodamaiajr/sample-ddd.

5.1 Criando modelo de um domnio

Com o DDD deve-se comear pela parte mais importante de um sistema, o domnio. nele que
se concentraro todas as regras de negcios do sistema, sendo assim, o corao da aplicao. A
figura 4 do apndice apresenta o modelo do domnio do sistema a contendo duas associaes
ligadas entidade Pessoa. Uma a entidade PessoaEndereco e a outra PessoaContato,
onde, respectivamente, permitem o cadastro de endereo e de contatos desta pessoa. Todas as
classes deste diagrama representam as entidades do Domnio do sistema, e os Enums utilizados,
so objetos de valor. O Enum Genero define o gnero da pessoa, o Relacionamento define o tipo
de contato da Pessoa (amigo, familiar, entre outros); o Enum Endereco define o tipo do endereo
da pessoa(casa ou trabalho); o TipoContato, define o tipo do contato da pessoa (principal, casa,
celular, entre outros).
Um item relevante em domnio modelado seguindo as regras de orientao a objeto a poltica
definida para as entidades; todas so compostas por um ID que seja nico. Deste modo, todas as
tabelas do banco de dados tero um ID gerado automaticamente pela propriedade do banco de
dados utilizado; nesse caso ser utilizado o MySQL, onde o recurso de auto incremento ,
AUTO_INCREMENT.
Outro ponto importante quando se cria as entidades que os atributos so declarados como
virtual, isso permite que o NHibernate possa criar proxies dessas entidades devido ao uso do
recurso Lazy Loading que a O/RM utiliza. O Lazy Loading utilizado para melhorar a
performance na associao dos objetos, sendo assim, s sero alimentados os atributos no
momento em que forem utilizados. Este recurso se torna interessante nas situaes em que as
hierarquias so grandes, evitando que o NHibernate faa consultas com parmetros
desnecessrios ao banco de dados e que sobrecarregue as consultas sem necessidade tornando a
rotina mais demorada.

5.2 Repositrio

A camada de repositrio do domnio criada em uma camada separada da camada do domnio,
representada por projeto do tipo Class Library. Nesta camada so criadas as Interfaces que
definem a camada do repositrio do domnio da aplicao.
Essas interfaces definem tudo que o domnio da aplicao necessita saber sobre a camada de
repositrio. As interfaces so o contrato dos mtodos existentes na camada de repositrio.
nessa camada que ficam todos os mtodos responsveis por efetuar as transaes do NHibernate
com o banco de dados relacional. A interface IRepositorioBase responsvel por abrir as sees
e conter todos os mtodos necessrios para interagir com o banco de dados relacional atravs do
NHibernate, alm de possuir outros mtodos j pr-definidos, como os mtodos de CRUD os
quais so genricos para dar um ganho no desenvolvimento do sistema e evitar que seja criado as
mesmas rotinas no outros repositrios, onde as demais interfaces herdam da interface
IRepositorioBase, conforme apresenta o diagrama de interfaces do repositrio na figura 5 do
apndice.
Para que o NHibernate possa realizar as transaes com o banco de dados relacional, necessrio
que as entidades do domnio sejam mapeadas com o FluentNHibernate. Na figura 6 possvel ver
o mapeamento da entidade Pessoa a qual mostra o conceito de um-para-muitos, onde uma Pessoa
pode possuir diversos endereos e diversos contatos, sendo assim, com o NHibernate necessrio
mapear essas duas propriedades com as regras de HasMany do NHibernate juntamente com o
Fluent NHibernate.

Figura 6 - Mapeamento da entidade Pessoa com Fluent NHibernate

public class PessoaMap : ClassMap<Pessoa>
{
public PessoaMap()
{
Table("pessoa");
Id(x => x.PsaId, "ID");
Map(x => x.PsaNome, "NOME");
Map(x => x.PsaSobreNome, "SOBRE_NOME");
Map(x => x.PsaDataNascimento, "DATA_NASCIMENTO");
Map(x => x.PsaDataCadastro, "DATA_CADASTRO");
Map(x => x.PsaGenero, "GENERO");
Map(x => x.PsaRelacionamento, "RELACIONAMENTO");
HasMany<PessoaEndereco>(x => x.ListaPessoaEndereco).Table("pessoaendereco")
.KeyColumn("PESSOA_ID").Not.LazyLoad()
.Cascade.AllDeleteOrphan();
HasMany<PessoaContato>(x => x.ListaPessoaContato).Table("pessoacontato")
.KeyColumn("PESSOA_ID")
.Not.LazyLoad()
.Cascade.AllDeleteOrphan();
}
}
Fonte: O Autor

5.3 Servios do domnio

nos servios do domnio onde se concentram todas as regras de negcios do sistema, assim
como no repositrio se concentram as partes responsveis por realizar todas as transaes do
NHibernate com o banco de dados relacional. Sendo assim, para tornar o modelo de DDD
completo, necessrio implementar a estrutura de servios do domnio. Em uma aplicao de
negcio as regras de negcios esto relacionadas a operaes de persistncia de dados, ou seja,
dependem de um repositrio.
Para que um servio possa acessar os repositrios necessrios para criar a regra de negcio, o
repositrio injetado no servio atravs do construtor do servio, evitando, assim, o acoplamento
entre o domnio e a camada de persistncia por ser injeo de dependncia. A figura 7 mostra
como feita a injeo do repositrio, isso permite que os mtodos possam efetuar transaes com
o banco de dados, se necessrio.
Com isso as camadas de domnio e repositrio esto de acordo com o modelo sugerido por Evans
(2009), permitindo a criao das Views do sistema.

Figura 7 Servio do Domnio Pessoa


Fonte: O Autor

5.4 Consumindo os servios do domnio

Com a parte de modelagem do domnio concludo possvel consumir os servios, seja em uma
aplicao Desktop, Web ou Mobile.
Neste caso ser apresentado como consumir o servio em uma aplicao Desktop, utilizando
Console Application. Para efetuar o consumo dos servios do domnio, necessrio referenciar as
duas Class Library criadas, a Agenda.Dominio onde se encontra a camada de regras de negcios,
e a Agenda.Repositorio onde est toda a parte de persistncia do sistema com o banco de dados
atravs do NHibernate. Na figura 8, encontra-se como o servio instanciado e consumido, onde
feita a injeo de dependncia do repositrio de forma concreta do domnio. Uma vez
instanciado, possvel chamar todos os mtodos que esto disponveis no servio. Nesse caso, foi
instanciado o servio PessoaServico e solicitado o consumo do mtodo
RetornaTodasPessoas, conforme apresentado na figura 9, onde o mtodo retorna uma lista de
todas as pessoas cadastradas na agenda e apresenta na tela o resultado conforme a figura 10.

Figura 8 Instanciando o servio PessoaServico

// Instanciando o servio PessoaServico e injetando o repositrio no servio de Domnio
static readonly PessoaServico _pessoaServico = new PessoaServico(new PessoaRepositorio());

Fonte: O Autor

Figura 9 Consumo do mtodo RetornaTodasPessoas do servio PessoaServico




Fonte: O Autor

Figura 10 Apresentao dos valores do mtodo RetornaTodasPessoas no Console Application



Fonte: O Autor

6 RESULTADOS OBTIDOS

Com a implementao do modelo adotado por Evans, pode-se observar a facilidade de reutilizar
as regras de negcios em diferentes plataformas sem ter a necessidade de efetuar alteraes ou
adaptaes. Alm da facilidade de criar novas rotinas permitindo a escalabilidade das aplicaes
com qualidade e sem afetar o desempenho e o usurio final.
A utilizao dos frameworks NHibernate e FluentNHibernate facilitou no momento de fazer as
persistncias com os bancos de dados relacionais, onde os mapeamentos das entidades realizados
com o FluentNHibernate permitiu um ganho na hora do desenvolvimento, pois ao invs de ficar
criando os mapeamentos no padro XML, ele permitiu que o mapemanto fosse realizado no
prprio cdigo fonte sem ter a necessidade de criar os arquivos no padro do NHibernate, os
HMB. Evitando, deste modo, que haja problemas futuros devido inscrita incorreta de algum
atributo ou configurao por no ser uma linguagem tipada, o FluentNHibernate trabalha no
formato de linguagem tipada conforme apresentado na figura 6, permitindo efetuar as correes
apresentadas pelo prprio compilador j com o NHibernate, o compilador no detecta os erros
permitindo a compilao dos fontes com os erros de mapeamentos. Sendo assim, seria possvel
apenas detectar as falhas somente aps a compilao dos cdigos fontes e uso da aplicao.

7 CONCLUSO

A elaborao deste artigo teve como objetivo principal a apresentao de um novo modelo e
melhorias na rea de arquitetura e modelos de software, o Domain-Driven Design (DDD). Este
paradigma foi criado e modelado por Eric Evans com um nico objetivo, focar no modelo do
domnio, chamado de corao do sistema, o qual permite que o sistema seja desenvolvido em
camadas, com qualidade e permitindo o desenvolvimento de forma escalvel, sem afetar as outras
camadas.
Pode-se concluir que a utilizao do DDD no desenvolvimento de novos projetos uma deciso
positiva para a equipe de desenvolvimento e tecnologia, de modo que se podem tirar diversos
benefcios dessa modelagem, permitindo que uma vez modelado o domnio, seja possvel
consumir os servios em qualquer tipo de aplicao, seja ela Desktop, Web ou at mesmo para
dispositivos mveis. Alm de poder aplicar o uso do framework NHibernate para transaes com
bancos relacionais juntamente com outro framework, o Fluent NHibernate,o qual permite efetuar
o mapeamento das entidades de forma mais clara e produtiva, ambos so totalmente open source,
mantidos por comunidades. Com isso, foi possvel verificar que com o uso dos dois frameworks
O/RM em conjuntos no repositrio do domnio, permite que o desenvolvedor possa extrair o que
tem de melhor desses frameworks, sem se preocupar em como os dados sero armazenados e
recuperados do banco de dados relacional.
Vale ainda ressaltar que o modelo apresentado neste artigo um modelo que vem sendo adotado
na indstria de software devido facilidade de implementao, pois permite o crescimento
escalvel do sistema sem perda de qualidade, alm de facilitar a manuteno quando necessria.
Outro aspecto importante que para a implementao do DDD, necessrio que haja
conhecimento na programao orientada a objetos, onde envolve todos os cenrios; O que, muitas
vezes, dificulta o entendimento do modelo sugerido por Evans, caso no haja conhecimento e
domnio sobre orientao a objetos, pode levar a impactos na modelagem do sistema, afetando o
resultado final devido a falhas na modelagem.

REFERNCIAS

EVANS, ERIC. Domain-Driven Design: Atacando as Complexidades no Corao do Software.
So Paulo: Alta Books, 2009.

GREGORY, JAMES. Fluent NHibernate. Disponvel em: <https://github.com/jagregory/fluent-
nhibernate/wiki/Getting-started>. Acesso em: 10 jan. 2014.

HIBERNATE. Hibernate - ORM . Disponvel em: <http://hibernate.org/orm>. Acesso em: 10
jan. 2014.

LINWOOD, J; MINDER, D. Pro Hibernate 3: Learn how to use this highly popular Open
Source, lightweight, object-relational mapping (ORM) tool for Java. ed. Estados Unidos da
Amrica: APRESS, 2005.

NHFORGE. NHibernate - Wiki. Disponvel em: <http://nhforge.org/wikis>. Acesso em: 10 jan.
2014.

PERKINS, Benjamin. Working with NHibernate 3. ed. Estados Unidos da Amrica: WILLEY
PUBLISHING, INC, 2011.

PETERS, J. F.; PEDRYCZ W. Engenharia de Software: Teoria e Prtica. 2. ed. Rio de Janeiro:
Campus, 2001.

PRESSMAN, Roger S. Engenharia de Software: Uma Abordagem Profissional. 7. ed Porto
Alegre: AMGH, 2011.


DEVELOPMENT OF A PRACTICAL APPLICATION WITH DDD - DOMAIN DRIVEN
DESIGN, NHIBERNATE AND FLUENT NHIBERNATE
The success in developing applications is not connected only the final results, but rather used
technologies and architectural models which allow applications to be developed with quality,
easy scalability and maintenance without affecting the final outcome and ensuring quality and
satisfaction of application to customers. This article aims to explain the template created by Eric
Evans, the DDD Domain Driven Design which focus on development and modeling is
connected to the field of application ensuring scalability, easy integration with other platforms,
quality and easy maintenance. In addition, it will be made use of O/RM framework, NHibernate
with Fluent NHibernate for the mapping of objects and persistence of data in the relational
database, where this O/RM allows the developer doesn't worry how application transactions are
performed with the database, and Yes, only with the application domain where your repository
will be responsible to perform all transactions with NHibernate, ensuring performance and that
the application is compatible with all major relational databases.
Keywords: Domain-Driven Design. NHibernate. Fluent NHibernate.


APNDICE DIAGRAMAS DE MODELO DO DOMNIO

Figura 4 Modelo do domnio do sistema



Fonte: O Autor

Figura 5 Diagrama de estrutura de interfaces do repositrio



Fonte: O Autor