Apresento-lhes um resumo que fiz durante meus estudos para uma prova de Analise e Projeto de Sistemas. É bastante resumido, mas contém alguns pontos importantes que devem ser lembrados.
Resumo feito do capítulo 10 do livro do Craig Larman.

Introdução

Um modelo de domínio é amplamente utilizado como fonte de inspiração para projetar objetos de software e será um dado de entrada requerido por vários artefatos subsequentes. O modelo de domínio ilustra as classes conceituais significativas (para os modeladores) em um domínio de problema; é o artefato mais importante a ser criado durante a análise orientada a objetos1.

Identificar um conjunto rico de objetos ou de classes conceituais está no cerne da análise orientada a objetos e é um esforço que vale a pena pelo retorno que traz na fase de projeto e implementação.

Um modelo de domínio é uma representação de classes conceituais do mundo real, não de componentes de software. Ele não é um conjunto de diagramas que descreve classes ou objetos de software com responsabilidades.

Modelos de Domínio

O passo mais essencialmente orientado a objetos na análise ou na investigação é a decomposição de um domínio de interesse em classes conceituais e objetos individuais – os quais nos interessam. Um modelo de domínio é uma representação visual de classes conceituais, ou objetos do mundo real, em um domínio de problema. Usando a notação UML, um modelo de domínio é ilustrado como um conjunto de diagramas de classes, nos quais não se definem operações.

A informação que ela ilustra (usando a notação UML) poderia ter, de forma alternativa, sido transmitida por texto em prosa, por sentenças no Glossário ou em um outro lugar qualquer. Entretanto, é fácil compreender os elementos discretos e seus relacionamentos nesta linguagem visual.

Na análise estruturada, o critério para a decomposição são os processos ou as funções. Porém na análise orientada a objetos, a dimensão de decomposição usada é fundamentalmente realizada por meio de coisas ou entidades do domínio.

Identificação de Classes Conceituais

Nosso objetivo é criar um modelo de domínio composto de classes conceituais interessantes ou significativas no domínio de interessse.

Não pense que um modelo de domínio será melhor se tiver menos classes conceituais; a verdade tende a ser exatamente o oposto. É melhor especificar em excesso um modelo de domínio com muitas classes conceituais de granularidade fina do que subespecificá-lo.

Não exclua um conceito somente porque os requisitos não indicam uma necessidade óbvia de lembrar informações sobre ele ou, ainda, porque o conceito não tem atributos. É perfeitamente válido ter classes conceituais sem atributos, ou que têm um papel puramente comportamental no domínio, em vez de um papel de informação.

Estratégia para identificar classes conceituais

Uma técnica útil por sua simplicidade, é a análise linguistica: identificar os substantivos e as frases que podem estar no lugar de um substantivo, nas descrições textuais de um domínio de problema, e considerá-los como candidatos a classes conceituais ou atributos.

Porém deve-se tomar cuidado ao aplica reste método; não é possível um mapeamento mecânico de substantivos para classes conceituais, e as palavras em uma linguagem natural tendem a ser ambíguas.

O modelo de domínio é uma visualização de conceitos e de vocabulário do domínio dignos de nota. Onde eles se encontram? Nos casos de uso. Assim, eles representam uma rica fonte a ser explorada pela identificação de frases nominais (substantivos ou frases que podem, em uma sentençã, ocupar o lugar de um substantivo).

Uma dica para diferenciar classes conceituais de atributos

Talvez o engano mais comum na criação de um modelo de domínio seja representar algo como um atributo quando ele deve ser um conceito. Uma regra prática para ajudar a evitar esse engano é a seguinte:

Se você consegue pensar em uma classe conceitual X como um número ou um texto no mundo real, então X provavelmente será um atributo, e não uma classe conceitual.