Está definindo cada método / estado por objeto em uma série de diagramas UML representativos do MDA em geral?

5

Atualmente, estou trabalhando em um projeto em que usamos uma estrutura que combina geração de código e ORM junto com a UML para desenvolver software. Métodos são adicionados a classes UML e são gerados em classes parciais, onde "coisas acontecem". Por exemplo, uma classe UML "Content" poderia ter o método DeleteFromFileSystem (void). Que poderia ser implementado assim:

public partial class Content
{
    public void DeleteFromFileSystem()
    {
        File.Delete(...);
    }
}

Todos os métodos são projetados assim. Tudo acontece nessas gigantescas classes de domínio de bombas lógicas.

É assim que MDA, DDD ou similar geralmente é feito? Por enquanto a minha impressão de MDA / DDD (que isto tem sido chamado por highups) é que isso prejudica minha produtividade (tudo deve ser feito The Way) e que dificulta o trabalho de manutenção já que toda a lógica está amarrada, entrincheirada, intercalada na mencionada bombas gigantescas.

Por favor, abster-se de interpretar isso como um discurso - estou apenas curioso para saber se isso é típico MDA ou algum tipo de MDA extrema

UPDATE

No que diz respeito ao exemplo acima, na minha opinião, o Conteúdo não deve lidar com a exclusão como tal. E se mudarmos do armazenamento local para o Amazon S3, nesse caso teríamos que reimplementar essa funcionalidade espalhada por vários locais, em vez de uma única interface para a qual podemos fornecer uma segunda implementação.

    
por Max 08.06.2011 / 16:38
fonte

4 respostas

1

O DDD não requer que você tenha uma classe para gerenciar seu próprio armazenamento; na verdade, o DDD tem o conceito de um repositório para lidar com armazenamento. O que você está fazendo altos é fazer com que você implemente o Active Record e vincule a implementação à classe, em vez de ocultá-la da classe.

    
por 07.06.2012 / 01:42
fonte
0

Sim, algumas equipes modelam o nível do atributo e fornecem assinaturas de método detalhadas. Eu realmente não acompanho a parte sobre a bomba lógica gigantesca; Existe lógica colocada nas classes de domínio que não deveria estar lá? O exemplo que você fornece não parece inadequado.

    
por 08.06.2011 / 17:59
fonte
0

Você não precisa do MDA para esse tipo de geração de código de diagrama de classe UML. Código ao vivo e sincronização de modelos é para mim mais apropriado. O MDA é mais um tipo de modelagem de um nível mais alto de abstração e geração de código. O código é apenas um empurrão de cima para baixo. Uma vez gerado, o código não tem mais relação com o modelo e é impossível retroceder. O código ativo e a sincronização do modelo é mais fácil e melhor que o MDA.

    
por 10.06.2011 / 11:24
fonte
0

Acho que isso é um problema com a maneira como suas ferramentas geram código. Se eu entendi bem, você lamentou sobre o fato de que as ferramentas criam arquivos de origem de "classe parcial" para cada método (em vez de um arquivo de origem por classe). Eu concordo que isso é bastante estúpido e torna o resultado difícil de usar e manter, mas isso não é típico de MDA ou DDD. Na verdade, uma ferramenta não pode fazer isso em outros idiomas, por exemplo, Java, que não permitem arquivos de origem de "classe parcial".

    
por 10.06.2011 / 11:31
fonte

Tags