O termo domínio é utilizado para denotar ou agrupar um conjunto de sistemas ou de áreas funcionais que exibam funcionalidades similares.
Exemplos de domínio incluem:
- Domínio de Telecomunicações
- Domínio Logístico Atacadista
- Domínio Bancário
- Domínio de Seguros de Saúde
- Domínio Acadêmico Escolar
Podemos então descrever o domínio aplicacional como sendo uma coleção de aplicações de software que partilham um determinado conjunto de características. Da mesma forma, o domínio é definido por um conjunto de características que descrevem uma família de problemas para os quais uma determinada aplicação pretende dar solução.
Um modelo de domínio é um artefato comum em várias metodologias (RUP ou escolas ágeis) usado para expressar um determinado domínio, normalmente em linguagem UML.
Antes de definir este artefato, vamos dizer o que não é este modelo. Um modelo de domínio não é um diagrama de classes em nível de análise, um diagrama de classes em nível de desenho, muito menos um modelo de entidades e relacionamentos (DER). Um modelo de domínio não carrega informaçães técnicas (Java ou C#), que devem estar presentes em um modelo de desenho. Um modelo de domínio também não carrega todo o detalhamento do comportamento e estrutura (operações e atributos), que devem estar presentes em um modelo de análise. Um modelo de domínio também não carrega informações de armazenamento de informações ou normalizações, que devem estar presentes em um DER.
Mas, afinal, o que é um modelo de domínio?
1. Um modelo de domínio é um produto da modelagem de negócios, i.e., ele representa, em certa escala, o negócio sendo modelado e compreendido.
2. Um modelo de domínio deve, por consequência, ser realizado inicialmente pelos analistas de negócios e usuários do projeto, e revisado e complementado pelo máximo de participantes de um projeto. O modelo de domínio deve ser um artefato colaborativo, compartilhado por todo o time do projeto.
3. Um modelo de domínio captura o vocabulário do sistema ou negócio sob modelagem. Como exemplo, um modelo de domínio de um sistema acadêmico de uma faculdade irá possuir os elementos Aluno, Professor, Curso, Disciplina ou Matrícula, entre diversos outros. Podemos perceber, então, que o modelo de domínio expressa o glossário do negócios sob modelagem.
4. Um modelo de domínio é uma representação lógica e estrutural de elementos do domínio e seus relacionamentos. Um diagrama de classes UML possui os elementos necessários para esta estruturação. Normalmente os conceitos de classes, associações e generalizações são suficientes para estruturar um modelo de domínio. Como consequência, um modelo de domínio não captura interações temporais ou representações físicas de modelagem.
5. Um modelo de domínio expressa uma visão conceitual preliminar acerca de um sistema e é chamado de diagrama de classes conceitual por alguns autores. Um exemplo extraído do excelente site do Scott Ambler (http://www.agilemodeling.com) de modelagem de domínio representa esta idéia.
(c) Scott Ambler, 2003-2006.
6. Um modelo de domínio deve ser feito no começo do projeto. Temporalmente, ele deve ser expresso e ganhar maturidade até o primeiro décimo do projeto. Por exemplo, se você tem na sua mão uma demanda de dois meses, devemos conseguir um modelo de domínio relativamente estável até o fim da primeira semana. Isso requer, como pode ser imaginado, um esforço intenso com os usuários chave para capturar o vocabulário, glossário e representá-lo em UML.
7. Um modelo de domínio (enquanto artefato) não precisa ser evoluído formalmente no restante do projeto. Isto pode parecer estranho, mas o objetivo do modelo de domínio é capturar o negócio e servir de insumo para a geração de modelos mais formais como o diagrama de classes ou o DER e depois o código executável. Em outras palavras, podemos imaginar o modelo de domínio como um estágio evolucionário para gerarmos os diagramas estruturais, comportamentais e o código de um projeto de software. Cabe citar que o modelo de domínio, enquanto conceito, como bem capturado pelas resenhas a este blog, evolui sempre, isto é, o diagramas de classes, o DER e o código também refletem conceitualmente o domínio do problema e por isso podem ser entendidos como “modelos de domínio”.
8. Um modelo de domínio também é um padrão arquitetural para a modelagem de sistemas OO, padrão este que encapsula lógica de negócios e dados em entidades coesas. Uma referência mais densa sobre este aspecto pode ser encontrada no excelente livro Patterns of Enterprise Application Architectures (http://martinfowler.com/books.html#eaa), do autor Martin Fowler. Recomendo também o artigo Anemic Domain Model (http://www.martinfowler.com/bliki/AnemicDomainModel.html) como anti-exemplo do uso deste padrão.
9. Um modelo de domínio pode carregar padrões de análise. Um padrão de análise não é um padrão técnico (desenho ou arquitetura), mas uma representação conveniente para expressar um aspecto de negócio em sistemas de informação. Exemplos de padrões de análise envolvem a representacão de quantidades (monetárias ou medicamentos), a representação de faixas de valores (início/fim), padrões contábeis (parcelamentos de dívidas, contratos) ou representação de papéis (roles). O site sobre Analysis Patterns (http://martinfowler.com/articles.html#ap) do autor Martin Fowler traz informações valiosas sobre este tópico.
Se você não entendeu nada até o momento, um exemplo pode ajudar a colocar alguma luz neste conceito. Vamos assumir que você precise representar o domínio de sistemas de gestão da geração e transmissão de energia elétrica. Um modelo de domínio que mostra este negócio em termos de seus elementos (ex: transformador, consumidor de energia) e relacionamentos é mostrado aqui.
Compilo aqui, para os mais interessados neste artefato e nesta técnica, uma lista de referências mais técnicas de modelagem de domínio de vários especialistas de mercado.
. 