rodrigoy:
Bom senso... bom senso... bom senso... desenvolvimento de software se resume a bom senso!
Rodrigo, sei que o post já é meio antigo, porém toda discussão que gera idéias magnificas como este, considero-o de suma importância dentro do contexto. Portanto, segue alguns questionamentos e dúvidas de minha parte:
1. Eu sempre fui adepto a desenvolver software usando padrões arquiteturais do GoF(Strategy, Facade, Singleton, Composite) e os Patters da SUN para especificação J2EE(Não estou dizendo que no DDD não usamos esses patterns), detalhe isso quando precisei de usar os tais (Não usei só prá dizer que usei padrão XY e Z) e outra o que estou me referindo e da arquiteturra BOLOVO (BusinessLayer, LayerObject, ValueObject)..usando e abusando de Transaction Scripts(Como você citou no teu blog) gerando um forte acoplamento entre as classes e quebrando e diminuindo a coesão (SRP - Principio da Responsabilidade Unica).
Porém agora estou desenvolvendo meu projeto (ERP segmentado para o ramo varejista) dirigido ao Dominio (DDD). Já andei lendo o livro do Evans, os Posts do Fowler, Adam Bien, GUJ..efim, revirei tudo antes de iniciar um projeto com DDD. Percebi que no DDD existem os Patterns que o acompanham e os anti-patterns, que porcerto contrariam os principios. vi aqui: http://www.infoq.com/articles/ddd-in-practice. Observei também que deve ser usar uma linguajar de negocio na manipulação dos artefatos, visto que todos envolvidos, Team, StakeHoldes, ScrumMaster, ProductOwner falam a mesma lingua(linguagem do dominio). Uma coisa que achei interessante no teu http://blog.aspercom.com.br/2009/08/11/repositorios-ddd/, você comentou também acerca de nomeclaturas, ou seja, eu tenho um repositorio de Pedidos, então não
sou obrigado a chama-lo de PedidoRepository, ou melhor, nem vejo isso como obrigação ou posso até está sendo tolo em ser influênciado a fazer isso, porquanto trata-se de convenção, afim de faclitar a idenficação, No Entanto eu concordo contigo, imagina o cliente ver esse diagrama de classes , será que ele vai saber o que significa esse tal de PedidoRepository? Pergunto isso porque muitos estão se levando a fazer isso, ou seja, colocar como sufixo da classe o nome do Pattern e eu estava pensando em fazer isso, porém nos Exemplos que achei pela net inclusive o proprio exemplo usando pelo Evans do Sistema de Transporte de Carga a interface se chama CargoRepository. É obvio que cada caso é um caso, e como você disse temos que ter Bom senso, e nesse caso eu acho que você usou o bom senso, porquanto eu achei extremamente lógico a tua colocação, eu achei mais limpo e mais claro na visão de Business Expert.
(Lembrando que to fazendo papel de Domain Expert tambem, porquanto conheço o ramo de negocio por 7 anos)
package se.citerus.dddsample.domain.model.cargo;
import java.util.List;
public interface CargoRepository {
/**
* Finds a cargo using given id.
*
* @param trackingId Id
* @return Cargo if found, else {@code null}
*/
Cargo find(TrackingId trackingId);
/**
* Finds all cargo.
*
* @return All cargo.
*/
List<Cargo> findAll();
/**
* Saves given cargo.
*
* @param cargo cargo to save
*/
void store(Cargo cargo);
/**
* @return A unique, generated tracking Id.
*/
TrackingId nextTrackingId();
}
OBS: Esse CargoRepository está sendo implementado na camada de infraestrutura.
2. Outra coisa que eu queria te perguntar. Vocês estão falando acerca de Annotations, se usa-la dentro do Dominio estaremos poluindo nossas classes de dominio. Eu particulamente acho isso horrivel, se pudesse usar JPA sem annotations, se alguem conheçe me avisa, so não uso hibernate puro porque quero me beneficiar da JPA2. O que você acha disso? Uso Hibernate como implementação, sem anotação e sem chance de abstração ou JPA com anotação com N implementação e com chance de abstração do provider ORM?
3. Vou postar meu diagrama de projeto de classes aqui logo mais, e a estrutura das minhas classes como está ficando.
att
fidencio.
