14/09/13

Arquitetura Orientada ao Domnio | Srgio Taborda's Weblog

Srgio Tabordas Weblog

Alguns ensinam. Alguns fazem. O resto procura nos livros. Incio Blog Cincia Desenvolvimento

Entretenimento

Epistemologia Poltica

Type text to search here...

Arquitetura Orientada ao Domnio

Deixe o seu comentrio Go to comments A figura 1 mostra as peas base de uma arquitetura orientada ao domnio.

Ilustrao 1: Apenas como ilustrao a figura apresenta o domnio e outros andares da aplicao. Uma arquitetura baseada em servlets mostrada como ilustrao mas podemos pensar que o objeto Action representado na figura se refere a um objeto abstrato que tanto pode ser um objeto inicializado por um servlet, tanto um componente de uma interface swing. O ponto que o evento iniciado pelo usurio no andar de apresentao
sergiotaborda.wordpress.com/desenvolvimento-de-software/arquitetura/arquitetura-orientada-ao-dominio/ 1/14

14/09/13

Arquitetura Orientada ao Domnio | Srgio Taborda's Weblog

gera um evento, que de alguma forma, leva execuo de uma ao.

Aes de Leitura
Esta ao pode ser de dois tipos : leitura ou edio. As aes de leitura so passivas no sentido que no alteram o estado do sistema. Basicamente resumem-se a uma pesquisa no estado do sistema para poder mostrar algum tipo de informao ao usurio.Exemplos deste tipo de ao so a listagem de itens em uma lista ou a execuo de um relatrio. Neste tipo de aes estamos interessados em ler dados do estado do sistema. Muitas vezes o desafio aqui fazer essa leitura o mais economicamente possvel, ou seja, criando o mnimo de objetos possvel e ser o mais rpido possvel na execuo. Padro como Fastlane podem ajudar bastante a diminuir a carga sobre a aplicao. Estas aes esto interessadas em consultar o estado do sistema. Em sistema orientado ao domnio isso significa consultar um ou mais repositrios de entidades, j que nesta filosofia o conjunto de todas as instncias de todas as entidades que forma o estado do sistema. Isto representado na figura com uma seta apontando da ao para o repositrio. Esta estratgia permite que o repositrio seja informado com dicas para a extrao dos dados priorizando assim os interesses de leitura da ao ( ou seja, maximizando a eficincia de leitura )

Aes de Edio
Este tipo de aes alteram o estado do sistema. Por causa disso estas aes so, freqentemente, efetuadas em um ambiente transacional. Aqui o ponto no ser rpido, ter a certeza que o estado foi alterado de forma consistente. Vrios passos so seguidos para ter o mximo de certeza priori de que tudo vai acontecer com previsto e o sistema ter seu estado alterado corretamente. Estas verificaes preemptivas so normalmente chamadas: validaes. contudo esse termo causa grandes problemas de entendimento pelo que prefiro usar a expresso verificao de constrangimento. Para que a ao possa ser sequer tomada como candidata a poder alterar o estado do sistema todos os constrangimentos tm que ser verificados e a falha de algum deles inibe qualquer tentativa de alterao do estado do sistema. A comunidade de desenvolvimento normalmente associa edio como cadastro. Na realidade isto atrapalha mais que ajuda. O ponto que todos os sistema so dotados de aes de edio que alteram o estado do sistema. Seja esse estado traduzido como o conjunto de valores das propriedades de uma entidade, ou seja traduzido nos valores das propriedades de vrias entidades relacionadas, isso na realidade uma separao artificial daquilo que um software e faz. Portanto, no se pense que com aco de edio estou me referindo a edio de cadastros. No. Estou-me referindo a toda e qualquer ao que altere o estado do sistema. Porque, como j mencionei, o estado do sistema identificado com o estado das entidades do domnio em um sistema orientado ao domnio, ento as aes de edio tm que atuar inevitvelmente nas entidades do domnio. Contudo as aes no sabem quais entidades tm que ser alteradas, nem quais dados devem ser usados na alterao. Essa responsabilidade dos objetivos de Servio. Estes objetos so responsveis pela alterao do estado do sistema. Eles orquestram as entidades, seus estados e comportamentos para alterar o estado do sistema de alguma forma. Em particular formas de alterao diferentes so delegadas a servios diferentes de forma conforme o Principio de Separao de Responsabilidade. possvel, e at certo ponto, desejvel, que um servio coordene a atuao de outros servios. Este servio coregrafo na realidade um servio implementando o padro Faade. Este servio coregrafo necessrio para respeitar o Principio de Separao de Responsabilidade. Imagine por um momento que a
sergiotaborda.wordpress.com/desenvolvimento-de-software/arquitetura/arquitetura-orientada-ao-dominio/ 2/14

14/09/13

Arquitetura Orientada ao Domnio | Srgio Taborda's Weblog

ao necessita invocar o trabalho de vrios servios para completar uma alterao do estado do sistema. Ela estaria , de fato, orquestrando os servios do domnio, chamando para si a responsabilidade de saber quais servios chamar, em que ordem e com que parmetros tornando a ao em um objeto do domnio. Isto seria um absurdo j que, por definio, a ao no um objeto do domnio. Ento, conclumos que para manter a separao de responsabilidade a ao apenas pode invocar um servio do domnio. Esse servio poder invocar quantos outros servios quiser. O servio coregrafo ( Faade Service) apenas uma construo de importncia terica para distinguir dois tipos de servio: aquele que muda o estado do sistema, e aquele que delega essa alterao a mais do um outro servio. Estas necessidade de composio de servios recorrente, mesmo quando os servios no s do domnio, por exemplo: quando acontece a alterao de um dado no sistema um e-mail deve ser enviado informado o administrador. Esta necessidade de casar um servio que muda o dado, com um servio que envia o e-mail e tudo isso ainda dentro de um processo transacional tem que ser responsabilidade de um terceiro servio coregrafo. Como nota final sobra dizer que a ao de leitura tambm pode invocar um servio em vez do repositrio. Embora isso significa apenas que o servio ir delegar para o repositrio e portanto criando uma interferncia (aparentemente) intil do servio. A escolha sobre a visibilidade do repositrio pertence ao desenvolvedor. Se ele for precavido ele usar um servio de fachada ou , com um truque mais sutil um repositrio de fachada. Um desenvolvedor aventureiro pensar apenas no seu trabalho e no deixar a estrutura pronta para uma fcil extenso futura. um daquele dilemas que o desenvolvedor tem que resolver e que so o desafio da profisso

Montagem
Compreendido que a ao apenas pode tomar dois caminhos e invocar ora um servio, ora um repositrio comum que a ao seja responsvel por diminuir a impedncia entre as fronteiras do domnio e da aplicao passando a eles objetos tambm do domnio ( ou pelo menos, que paream objetos do domnio). Alguns destes objetos so complexos e comum que seja necessrio que eles tenham um relao direta com as entidades do domnio. Embora, tecnicamente , a instncia de uma classe s um objeto do domnio quando est sob o controle de um repositrio comum necessitar da mesma estrutura de dados em outros andares da aplicao. O exemplo comum us-los na Apresentao. A tentao de usar objetos da mesma classe de entidade grande e, na prtica, a tendncia atual. Ainda para mais em um sistema orientado ao domnio, isso faz todo o sentido. Assim, so criados instncias das classes de entidade dentro da ao. Essas instncias tm suas propriedades preenchidas pela ao e o resultado enviado ao servio. O servio entende esse objeto como um objeto do domnio e processa a lgica subjacente ignorando que, na realidade, esse no um objeto do domnio (j que no est sob a responsabilidade de um repositrio). Isto causa problemas ao repositrio. Sendo que o objeto que lhe foi passado no est no domnio ( no controlado pelo repositrio), o repositrioassume que se trata de uma nova instncia de uma entidade e tenta presev-la atribuindo-lhe uma identidade. Esta identidade inferida do objeto e isso pode levar a erros. Como no ha certeza da identidade daquela instncia, o repositrio no pode fazer muito mais que isso. Ele sempre vai interpretar a chegada da instncia como uma adio ao estado atual e no uma alterao do estado atual. Para tentar colmatar o problema temos a figura do Assembler (Montador). Este objeto um delegado do
sergiotaborda.wordpress.com/desenvolvimento-de-software/arquitetura/arquitetura-orientada-ao-dominio/ 3/14

14/09/13

Arquitetura Orientada ao Domnio | Srgio Taborda's Weblog

domnio em outros andares. Ele sabe como montar a instncia a partir de objetos de no-dominio (como mapas, por exemplo) e identificar a identidade do objeto se ele estiver presente nesses objetos que lhe so passados. Ele sabe tambm como, dado uma instncia do domnio, desmembr-la em objetos de nodomnio, atuando como um DesAssembler (Des-Montador)

O Repositrio
O repositrio tem como objetivo ser o localizador de instncias das entidades que compem o estado do sistema. Para o resto da aplicao indiferente onde essas instncias realmente esto. Se elas jazem num banco de dados, na memria, um uma nuvem de processamento, um arquivo xml , um sistema de prevalncia ou simplesmente codificadas num feixe de luz, no importa. Mas para o repositrio importa. Afinal ele responsvel por manter esses dados consistentes e vrias coisas podem dar errado nesse trabalho. Uma outra responsabilidade do repositrio prover mecanismos para que uma instncia de uma entidade encontra uma outra instncia de uma outra entidade (ou da mesma) com a qual est relacionada. Afinal a instncia pode ser um grafo de objetos o que seria otimo mas a constante alterao dessas instncias pelos servios torna o grafo uma estrutura estressante para o domnio. Contudo, essa estrutura pode ser simulada com a ajuda do repositrio. Afinal, para que uma instancia encontre a outra basta apenas saber a identidade dessa outra instncia ou alguma regra que relaciona as duas. A procura em si, o repositorio executa. O repositrio livre de preservar as instncias como e onde quiser, contudo, hoje em dia, a facilidade oferecida pelo padro DomainStore torna tudo muito mais simples.Uma implementao de DomainStore pretende oferecer preservao do estado dos objetos do domnio que formam o estado do sistema da forma mais transparente possvel. Poderamos argumentar se as implementaes atuais entregam essa promessa, mas o ponto que sempre ser necessrio escolher uma implementao especifica desse padro; mesmo que seja uma implementao feita por voc. esta a responsabilidade do Repositrio, escolher e comunicar com um DomainStore e us-lo para prover as informaes pedidas pelos servios (e/ou aes).

Critrios de Pesquisa
Uma das funcionalidades mais importantes em um sistema de informao com estado poder pesquisar informaes desse estado. Em sistemas orientados ao domnio isso significa pesquisar por instncias de entidades que respeitem certas regras. Que respeitem certos critrios de pesquisa. Estes critrios so, eles mesmos, objetos. Objetos normalmente implementando o padro QueryObject. Contudo estes objetos so normalmente complexos de criar por conterem muitas propriedades e variaes possiveis. comum necessitar de um objeto Builder para ajudar na sua criao. Existem dois usos para os critrios de pesquisa. a) o servio montar um critrio para procurar algo no repositrio; b) o repositrio monta um critrio para procurar algo no DomainStore ( supondo que ele aceita este padro como input). No primeiro caso queremos que o builder do critrio seja o mais simples possvel e que, se possivel, utilize os conceitos do domnio. Aqui normalmente somos tentados a dotar esse builder de uma interface fluente para facilitar a escrita e deixar tudo mais coerente com o propsito do domnio. No segundo caso o repositorio tem que consumir o builder disponibilizado pela API do DomainStore que est utilizando (se uma existir). Se o desenvolvedor escolher usar critrios de pesquisas nos dois casos, o repositorio ser obrigado a traduzir um critrio para o outro. Se isso acontecer, ele dever delegar essa
sergiotaborda.wordpress.com/desenvolvimento-de-software/arquitetura/arquitetura-orientada-ao-dominio/ 4/14

14/09/13

Arquitetura Orientada ao Domnio | Srgio Taborda's Weblog

tarefa a um objeto que implemente o padro Interpreter para que um critrio seja compilado em outro. O importante que, do ponto de vista do servio no existe nenhum outro critrio alem daquele que ele cria. Como nota importante chamar a ateno para o caso em que o desenvolvedor escolhe usar o builder e o critrio definido pela API do DomainStore como critrio e builder a ser usado pelo servio. Isso destri todo o objetivo da arquitetura orientada ao domnio pois agora o servio no mais estar fazendo pesquisas sobre instncias no repositrio, mas sob objetos de dados controlados pelo DomainStore. Isto uma quebra de encasuplamento e viola diretamente o Principio de Separao de Responsabilidade. Evite isso.

Licena
Srgio Taborda Este trabalho licenciado sob a Licena Creative Commons Atribuio-Uso NoComercial-No a obras derivadas 3.0 Genrica . Gosto
Be the first to like this.

Comentrios (11) Trackbacks (0) Deixe o seu comentrio Trackback 1. Roger Leite 2008/09/17 s 8:56 | #1 Resposta | Citao Parabns pelo artigo! Recentemente acabei de ler o livro de DDD do Eric Evans, e sabe como n, sempre ficam algumas dvidas ou mesmo detalhes a discutir. - Apesar de voc no citar, eu acredito que voc use o conceito de Value Object do DDD, por exemplo, a entidade Produto pode ter um atributo tipo, que este pode ser representado por um VO ProdutoTipo. Numa tela de cadastro do Produto, vamos supor que seja necessrio carregar um combo com todos os Tipos de Produto. Agora vem a pergunta, eu pego Todos os Tipos de Produto do ProdutoRepositorio (a entidade forte no caso) ou eu crio um TipoProdutoRepositorio ou devo pegar estes VOs de um ProdutoServico ? - Ainda no caso dos VOs eu preciso permitir que o usurio cadastre os Tipos de Produtos, o que fazer neste caso ? (Mesmo dilema da pergunta acima) - O papel do Assembler no diagrama daoless no est fazendo o trabalho da Factory de Entidade ? No faz sentido criar metodos assembler no Repositorio que este repassa para Factory ? - Esta a ltima eu prometo, . Como fica parte de controle de transao nos Repositorios ? Partindo da idia que o repositorio emula uma collection em memoria, para salvar as entidades, como posso fazer ? crio um mtodo add(Entidade) e no final executo um save ? O commit feito no Servio ? Valeu!
sergiotaborda.wordpress.com/desenvolvimento-de-software/arquitetura/arquitetura-orientada-ao-dominio/ 5/14

14/09/13

Arquitetura Orientada ao Domnio | Srgio Taborda's Weblog

Roger Leite 2. sergiotaborda 2008/09/17 s 10:25 | #2 Resposta | Citao Se vc permite que o usurio cadastre tipos de produto ento isso significa que o estado do sistema vai mudar conforme esse cadastro ( mais tipos, mais possibilidades) . Isso significa portanto que o tipo do produto no um VO e sim uma entidade. Logo, trate-o como uma entidade. Pegue os tipos do repositrio deles. O assembler pode usar a factory mas o seu trabalho no criar o objeto preencher as propriedades do objeto com informao que vem de outro lugar da aplicao ( da UI , por exemplo). Por exemplo, ele pode pegar um Map obtido de request.getParametersMap() e preencher os campos de uma entidade Produto fazendo algo como produto.setXPTO( map.get(XPTO)). A transao um processo controlado fora do repositrio, fora at do dominio. A transao pode ser iniciada pelo servio ou por algum mecanismo automtico que encapsule a chamada ao servio (padro Proxy) como se faz em EJB. O ponto que nem o repositorio nem o resto dos objetos do dominio com exceo , talvez, do servio no sabem sequer o que uma transao ou se esto em uma. 3. Daniel Bussade 2008/11/15 s 18:14 | #3 Resposta | Citao Ol Srgio, alguma coisas no ficaram claras para mim ai vo elas: Porque o service tem que acessar o repositrio, no poderia acessar diretamente o DomainStore? Acho at errado o service acessar o repositrio porque assim o repositorio obrigado a ter metodos de edio que mudem o estado do sistema como : public void add(T object){ session.save(object); //delegando pro domain store } public void remove(T object){ session.delete(object); } //Este metodo nao deveria estar aqui public void update(T object){ session.update(object); } O correto no seria deixar so as pesquisas no repositorio, alm das operaes de add e remove eh deixar as operaoes de update para o service que acessaria o DomainStore direto. O unico incomodo que vejo nisso eh que action teria que ter as duas classes por composio ou seja digamos uma ActionUsuario teria que ter
sergiotaborda.wordpress.com/desenvolvimento-de-software/arquitetura/arquitetura-orientada-ao-dominio/ 6/14

14/09/13

Arquitetura Orientada ao Domnio | Srgio Taborda's Weblog

public class ActionUser { private UserRepository ur; private UserService us; } Uma ultima duvida a funo do assembler seria algo parecido com isso: Digamos que tenha um cadastro de usuario em um form html com nome elogin e apos enviar a requisio e chegar na action, a propria teria o asssembler que faria este trabalho: public class ActionUser { private Assembler assembler; //Cada classe teria seu montador, ou seria um montador s para todas as classes? private UserService us; public void createUser(){ Usuario usuario=assembler.createUser(request.getParameterMap()); us.save(usuario); } } Desculpa o excesso de dvidas. Obrigado, seu blog tem me ajudado muito a arquiteturar melhor meus sistemas. Ou correto o 4. sergiotaborda 2008/11/17 s 8:38 | #4 Resposta | Citao Primeiro que tudo ha que entender que o repositorio primeiramente um objeto de procura. Nele esto encapsuladas as logicas (queries) para a procura. ele que sabe encontrar as instncias importantes paras os processos de negocio. O dominaStore sabe encontrar instancias com base em uma pesquisa genrica. Em comparao o DomainStore equivale a eu poder usar SQL. O SQL genrico e qualquer sistema o pode usar. Mas para cada sistema eu tenho frases especificas que quero usar. Esse o papel do Repositorio, definir e utilizar essas frases. O repositorio ser ou no editvel uma questo de gosto. S tem um pequeno seno. Quando o seu processo de edio no for um simples save o domainstore no aguenta sozinho. Ai vc ter que colocar a logica no service logica de persistencia no service ? = gambe. Logicas especiais so necessrios quando vc faz uso de value objects como money, por exemplo. Vc tem que saber onde guarda o amount e o currency e de onde os recuperar depois. Nem sempre do banco. O currencu, por exemplo, pode ser definido num properties. O ponto que o repositorio tb um ponto de extenso do dominio. Ele faz parte do dominio para isso mesmo. O domainStore no faz parte do dominio, ele apenas guarda o dominio. A action deve invocar o service. Sempre!
sergiotaborda.wordpress.com/desenvolvimento-de-software/arquitetura/arquitetura-orientada-ao-dominio/ 7/14

14/09/13

Arquitetura Orientada ao Domnio | Srgio Taborda's Weblog

public void createUser(){ Usuario usuario=assembler.createUser(request.getParameterMap()); try{ UsuarioService uservice = Services.getUsuarioService(); uservice.create (usuario); } catch (UserServiceException e){ // trata exception. por exemplo, redirecionando. } } } public classe SimpleUserService implements UsuarioService{ @Transactable public void create (Usuario user){ repositorio.save(user); } } public class EmailSendingUsuerService implements UsuarioService{ @Inject UsuarioRepository repositorio; @Inject EmailSenderService senderService; public void create (Usuario user){ // gera password aleatoriamente user.setPassword(password); // guarda repositorio.save(user); Email email = // monta email avisando o usurio que foi cadastrado e a sua passaword senderService.send(email); } } Outras implementaes seriam possiveis, a imaginao/ requisistos so o limite. O ponto que vc tem que dar a chance ao dominio de interferir com o fluxo das aes. para isso que ele existe. Se a action faz tudo, no ha como o dominio interferir.
sergiotaborda.wordpress.com/desenvolvimento-de-software/arquitetura/arquitetura-orientada-ao-dominio/ 8/14

14/09/13

Arquitetura Orientada ao Domnio | Srgio Taborda's Weblog

A action apenas uma das possiveis forma do dominio ser invocado. Por exemplo, poderiamos ter um webservice invocando o servio ou o servio correndo em um ESB. Se o servio est desacoplado facil integr-lo com outras tecnologias. Se tudo est escrito no action, isso simplesmente d muito trabalho. O action no pode executar logicas de negocio. Ele pode carregar dados e at fazer pesquisas , mas nada que altere o estado do sistema. 5. Daniel Bussade 2008/11/17 s 9:43 | #5 Resposta | Citao Obrigado Srgio novamente pelos esclarecimentos, o que acho estranho eh que o Service na maioria das vezes funcionara como um delegate apenas, tendo que duplicar metodos ou seja um metodo no Service e outro igual no Repository, mas compreendi que o Service tem que acessar o Repository e no o DomainStore direto, porque para alterar um Usurio tenho que antes fazer uma pesquisa para encontr-lo, por isso o Service tem que usar o Repositorio porque as frases ja estao montadas nele pronta para achar o Usuario. Um outro ponto no caso do Montador em cdigo falando era poderia ser traduzido para isto: public class Assembler(){ public User CreateUser(Map request){ User user=new User(request.getParameter(lnome),(request.getParameter(login)); } } Isso no seria uma Factory? O colega acima tinha a mesma duvida, ai voce disse que o papel do montador era colocar as coisas no lugar, eh que ele poderia usar uma factory, mas colocar as coisas no objeto que vem da UI por exemplo no seria criar ele? Ainda no ficou claro qual seria a diferena entre a Factory e o Assembler. Sendo assim o Assembler seria unico para todos no sistema ? tipo com metodo statics para cada classe do sistema, ou cada classse teria seu Assembler tipo AssemblerUsuario, AssemblerPedido, etc. Novamente obrigado! 6. sergiotaborda 2008/11/18 s 8:54 | #6 Resposta | Citao Primeiro o service no pode ser um delegate porque um delegate delega para um service. Delegate usado em sistemas distribuidos onde o servio realfica centralizado. O Delegate delega a operao para o servio real atravs da rede. O servio no est delegando ao repositrio. Ele est usando o repositrio. Operaes de validao, por exemplo, tm que ser feitas antes do save no repositorio. Chamada a outros servios , etc o caso em que o servio simplesmente chama o repositorio incomum. Mas
sergiotaborda.wordpress.com/desenvolvimento-de-software/arquitetura/arquitetura-orientada-ao-dominio/ 9/14

14/09/13

Arquitetura Orientada ao Domnio | Srgio Taborda's Weblog

mesmo nesse caso no ha nada de errado j que o servio pode eveoluir nas suas reponsabilidades. Factory um objeto responsvel pela criao do objeto. Ele substitui a operao new e a logica do construtor. O objetivo ter um objeto criado com estado vlido. Assembler um aroma de builder. Ele monta o objeto no no sentido que o cria (d new) mas no sentido que o preenche. Ele obtm dados de outro lugar e preenche o objeto. Normalmente esse lugar so os escopos da aplicao (request, session, parameters). O Assembler substitui uma longa lista de chamadas a setters no objeto e get do request. O Assembler pode utilizar o Factory para dar o new no objeto mas depois ir invocar os setters (modificadores). O factory no invoca os setters para alterar o estado, como o assembler faz, ele invoca os setters para setar o primeiro estado possvel para o objeto.Assembler derivado de Builder , no de Factory. Deveriamos cham-lo simplesmente de Builder, mas adotou-se o o nome Assembler para designar um builder especializado em montar o objeto a partir de dados que j existem em outro lugar (request, ejb, etc..) Em principio vc tem um assemble para cada entidade. Mas com reflection muito simples criar um assembler que funciona para qualquer bean. A conveno bean ajuda muito na hora de usar reflection. Um assembler neutro que use apenas bean procura pelos sets , interpreta o nome do campo e puxar do request. No meio pode fazer alguma converso de tipos j que o request s tem strings , ele pode converter para interios, booleanos, arrays etc.. sempre que se justificar. Em um assembler especifico de cada entidade vc faz essas converses mo porque j sabe que tipos est trabalhando. O BeanAssembler pode ser complexo, mas uma vez funcionando uma mo na roda. Outra coisa. normalmente quando a entidade vai para a tela ela tem um id. Esse id normalmente guardado num campo hidden e devolvido depois. Ento o assembler ir tambm settar o id como se fosse um outro campo. Isso importante para poder comparar o objeto criado pelo assembler, por exemplo para saber se se trata de uma edio ou de uma adio (adio o id nulo, edio o id no nulo) 7. Daniel Bussade de Almeida 2008/11/18 s 13:10 | #7 Resposta | Citao Ol, agora ficou tudo entendido sobre Assembler e Factory, achei muito interessante a ideia do BeanAssembler e vou tentar criar um. Um outro ponto quanto ao service eh o seguinte, no meu caso como uso um framework Web, as validaes ficam por conta dele como campoRequerido, DataInvlida, etc.. ou seja quando os dados chegam na action eu tenho certeza que esto vlidos ai simplesmente eu chamo o service que chamo o Repositorio eh salva o Objeto. Neste caso onde uso framework, voc no acha que o Service perde um pouco seu poder? Nesse sistema que estou construindo as regras de negocio permanecem todos no proprio Domain estou utilizando DomainDrivenDesign, voc acha valida fazer a inverso HTTP > Servlet > Action > Domain > Repository > SGDB Visto que assim poderia ter metodos deste tipo :

sergiotaborda.wordpress.com/desenvolvimento-de-software/arquitetura/arquitetura-orientada-ao-dominio/

10/14

14/09/13

Arquitetura Orientada ao Domnio | Srgio Taborda's Weblog

List lista=usuario.getPedidos();//Onde o Usuario tem um repositorio de Pedidos O que acha desta abordagem, a principio acho que quebra um pouco as camadas, mas vejo um q de interessante nela. Obrigado 8. sergiotaborda 2008/11/18 s 16:28 | #8 Resposta | Citao Hum O framework valida a apresentao. Imagine que vc usa o seu servio com uma apresentao de webservice. Quem faz a validao ? O servio no pode assumir que o que ele recebe est correto. Mesmo quando j foi verificado pela camada superior. O ponto que o servio no sabe que existe uma camada superior que faz validaes ( camadas inferirores no conhecem as superiores). Portanto, mesmo nesse cenrio vc precisa de validao, nem que seja para lanar um BusinessException. Domain contm servios e repositrios. Veja uma resposta anterior onde eu j falei isso. No ha problema nenhum com usuario.getPedidos excepto que usurios no tem pedidos, clientes que tm >; > List lista=usuario.asCustomer().getPedidos() 9. Tarso 2009/02/03 s 10:29 | #9 Resposta | Citao Parabns pelo artigo Srgio. Muito interessante o Assembler, especialmente o BeanAssembler que voc sugeriu em um dos comentrios anteriores. 10. Marcio Duran 2009/07/12 s 20:20 | #10 Resposta | Citao Realmente esse artigo esta altamente bom mas tambm altamente tcnico, apesar da Ilustrao acima do diagrama de dominio geral, bem que poderia desmenbrar em outros diagramas UML para no ficar s na narrativa, ao menos ficaria menos oculta informaes como(Padres que no foram ilustrados) e de melhor exposio a viso. BOM, s uma dica ; ) Abraosss
sergiotaborda.wordpress.com/desenvolvimento-de-software/arquitetura/arquitetura-orientada-ao-dominio/ 11/14

14/09/13

Arquitetura Orientada ao Domnio | Srgio Taborda's Weblog

11. naya mariamo 2010/03/11 s 16:00 | #11 Resposta | Citao adorei , voce esta de parabens sergio . voce deixo todo bem claro . bjx 1. No trackbacks yet. Tem de ter a sesso iniciada para publicar um comentrio. Feed RSS

Artigos recentes
O fuso e a roca Voto Consciente A Ecologia, a Sacola e a Cultura

Blog no Java Buinding

Com a inaugurao do JavaBuilding as minhas obervaes sobre desenvolvimento de software em geral e sobre Java e Scrum em particular podem agora ser seguidas no meu novo blog Caderno Srgio Taborda no JavaBuiliding. Este blog permance apenas para assuntos no relacionados a desenvolvimento de software.

Caderno no Javabuilding
Java EE 7 Arquitetura Padro Completa Pacotes, Camadas e Mdulos Otimizao Preventiva Java 8 Preldio O que gil significa Mtricas, Indicadores e Scrum

MiddleHeaven
Javadoc Disponivel Lista de Discusso Seis anos e muito para fazer
sergiotaborda.wordpress.com/desenvolvimento-de-software/arquitetura/arquitetura-orientada-ao-dominio/ 12/14

14/09/13

Arquitetura Orientada ao Domnio | Srgio Taborda's Weblog

Seguindo em frente No cu do meio Novo Conteudo Utilitrios: Colees aumentadas Nosso novo blog MiddleHeaven Pr-Alfa MiddleHeaven Reloaded

Twitter
Por uma melhor arquitetura e software mais barato. ow.ly/hZhQl 6 months ago Sobre pacotes, camadas e mdulos ow.ly/hOkC0 6 months ago Otimizao Prematura e Otimizao Preventiva, porque a primeira ruim e a segunda necessria. ow.ly/gu4XV 8 months ago Assistiremos a um revoluo com a chegada do Java 8 ? Lambdas vo salvar vc do tdio ? ow.ly/frLHI 9 months ago O que realmente significa gil. No seguir um manifesto, no adotar a prtica A ou B, mais que isso. ow.ly/f6Mbm 10 months ago

Meta
Registar Iniciar sesso RSS dos artigos Feed RSS dos comentrios. Blog em WordPress.com.

Pginas
Desenvolvimento de Software A Arte de Fabricar Software Arquitetura Arquitetura Orientada ao Domnio Arquitetura Web Java Colees: Como no usar Arrays Do DAO ao Domain Store Excees: Boas Prticas, Ms Prticas Excees: Classes Utilitrias Excees: Conceitos FAQ Primeiro Programa Sorteio aleatrio sem Repetio Trabalhando com Nmeros Igualdade em Java Introspeo java.lang.Object OO
sergiotaborda.wordpress.com/desenvolvimento-de-software/arquitetura/arquitetura-orientada-ao-dominio/ 13/14

14/09/13

Arquitetura Orientada ao Domnio | Srgio Taborda's Weblog

Herana Polimorfismo Separao de Responsabilidades e Encapasulamento Os 10 mandamentos do bom programador Java Palavras Reservadas Patterns Adapter Bean Builder Composite DAO Factory Factory Method Fastlane Iterator Money MoneyBag MVC Query Object Repository Singleton Transfer Object Value Object Scrum Equipe Planejamento Produto e Projeto Projees Sprint Valores Fsica Mecnica Quntica Livros Magic: The Gathering O Segredo do Magic Sobre mim Topo WordPress Blog em WordPress.com. The INove Theme.

sergiotaborda.wordpress.com/desenvolvimento-de-software/arquitetura/arquitetura-orientada-ao-dominio/

14/14