Fragmental

Tópico quente no GUJ. Muita gente está atrás de Domain-Driven Design hoje em dia e não tem a menor noção do que é um repositório.

Re-colando o trecho para a lista de DDD:

On 5/19/07, Phillip Calçado wrote:
> The main thing to keep in mind while working with Repositories is that
> they’re a domain concept, while a DAO or any other Mapper between
> objects and tables aren’t. The domain classes knows that repositories
> are where business objects instances remain. As a business concept it
> can and will be handled, received as a parameter, etc. by those
> business domain classes like services and entities.
>
> A DAO doesn’t fit in a Repositories place directly, this would break
> layered archtiecture of a application, but generally a Repository is
> just something that when invoked will call a DAO.
>
> To avoide the tortures of creating a brinless delegator as a
> Repository you can use the Dependency Inversion principle, by Uncle
> Bob, and make Repository an interface implemented by the DAO class.
> This way your domain classes won’t end up dependent on infrastructures
> classes (like DAOs) while you avoid creating Repository classes that
> acts just like delegators.
>
> I’ve used this approach more than once. In a recent project I’ve used
> this Dao<>Repository strategy and suddenly was requested
> that before checking the database I’d have to first check a enterprise
> search engine (something like google appliances or a dedicated Lucene
> server). I used to have:
>
> Domain Object –<>–> Repository <--<>– DAO
>
> And changed to:
>
> Domain Object –<>–> Repository
>
> Repository <--<>– RepositoryImpl –<>–> DatabaseDao
>
> –<>–>SearchEngineDao
>
> The RepositoryImpl was the class responsible for looking for the
> instance persisted in one of the two deta repositories. The domain
> classes that just relied on the Repository concept, not its
> implementation, weren’t affected.
>
> cheers
>
>
> On 4/25/07, Nick wrote:
> > I’ve just completed my third project using DDD principles and I think
> > I’m ready to move away from the repository pattern (though still
> > giving it some thought). In theory, I think it’s great. However, it
> > just causes so much code explosion, I find it’s just not practical.
> > For example, for the customer aggregate root I have:
> >
> > Domain.ICustomerRepository
>
>
>
> –
> Phillip Calçado
> http://www.fragmental.com.br

O DQO também colaborou.

This entry was posted on Tuesday, June 5th, 2007 at 2:51 pm and is filed under arquitetura, bancos.de.dados, engenharia, guj, java, orientacao.a.objetos, programando. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.