-
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: [email protected]. 2 Professor nos cursos de
graduao e ps-graduao na UNISOCIESC.
E-mail: [email protected].
-
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
Fonte: Fluent NHibernate (2010)
Figura 3 - Exemplo de um mapeamento via cdigo com o Fluent
NHibernate
-
public class EmployeeMap : ClassMap
{
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 { 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(x => x.ListaPessoaEndereco).Table("pessoaendereco")
.KeyColumn("PESSOA_ID").Not.LazyLoad() .Cascade.AllDeleteOrphan();
HasMany(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: . Acesso em: 10
jan. 2014.
HIBERNATE. Hibernate - ORM . Disponvel em: . 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: . 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
Flvio Antnio da Maia Jnior , Luiz Camargo
