approche Design (service commandé ou domaine Driven)

Question

Mon énoncé du problème est:

Je veux écrire la gestion des fichiers de conception (ajouter, copier, supprimer des opérations, etc.). Il y a deux approche:

1. service approche axée sur

fichier Write VO qui ne contient que des attributs de fichier. Par exemple

public Class File { 
    private boolean hidden; 
    private boolean read; 
    private boolean write; 

    public boolean isHidden() { 
     return hidden; 
    } 
    public void setHidden(boolean hidden) { 
     this.hidden = hidden; 
    } 
    public boolean isRead() { 
     return read; 
    } 
    public void setRead(boolean read) { 
     this.read = read; 
    } 
    public boolean isWrite() { 
     return write; 
    } 
    public void setWrite(boolean write) { 
     this.write = write; 
    } 
} 

et sépare le service pour les opérations liées aux fichiers. Par exemple :

public Class FileService { 
     public boolean deleteFile(File file) { 
      //Add delete logic. 
     } 
     //Same way you can add methods for Add and copy file. 
} 

2. approche Domain Driven (je peux me tromper ici.)

Où fichier VO contient tous les attributs ainsi que les opérations nécessaires:

public class File { 
    private boolean hidden; 
    private boolean read; 
    private boolean write; 

    public boolean isHidden() { 
     return hidden; 
    } 
    public void setHidden(boolean hidden) { 
     this.hidden = hidden; 
    } 
    public boolean isRead() { 
     return read; 
    } 
    public void setRead(boolean read) { 
     this.read = read; 
    } 
    public boolean isWrite() { 
     return write; 
    } 
    public void setWrite(boolean write) { 
     this.write = write; 
    } 
     public boolean deleteFile() { 
      //Add delete logic. 
     } 
     //Same way you can add methods for Add and copy file. 
} 

Alors, quels sont les avantages et les inconvénients de l'approche?

Answer 1

Sans beaucoup d'informations sur le type de système que vous voulez définir, c'est difficile à prononcer. Pour moi, le choix dépend des limites du système.

Si vous avez besoin d'offrir une API qui est exposée en tant que service et accessible au consommateur externe, optez pour la solution 1, c'est le seul moyen. Si votre système est plutôt une bibliothèque dont l'API sera utilisée en interne par d'autres applications, optez pour un modèle de domaine riche comme dans la solution 2, c'est beaucoup plus d'OO. Vous ne voulez pas gonfler votre API avec des classes de service, de gestionnaire et d'utilitaire pour lesquelles aucune raison réelle n'existe.

Mais encore une fois, sans connaître votre objectif final, c'est difficile à dire.

Answer 2

Dans un langage orienté objet, placer la logique dans la classe elle-même, plutôt que dans une classe de service, est l'approche typique (et mieux IMO). Il suit le principe "dire, ne demande pas", par exemple, en disant à un fichier de se supprimer, plutôt que de demander à un service de le supprimer. L'une des principales raisons derrière cela est de permettre l'héritage. Par exemple, si vous avez une sous-classe de Fichier et que vous voulez qu'elle écrive un message de journal avant qu'elle ne soit supprimée, ce serait difficile à faire avec une classe de service car vous auriez besoin d'une classe de service différente pour chaque sous-classe.

En termes d'approche orientée services, ceci est typiquement pensé à un niveau supérieur (c'est-à-dire une architecture orientée service). Envisager un système de stock financier, vous pourriez avoir un service "acheter des stocks" et un service "vendre des stocks". Avoir une classe de service qui correspond à des classes individuelles (c'est-à-dire un service Stock, qui sait comment acheter et vendre des actions) ne serait pas très orienté objet. Vous pouvez également avoir une couche de service dans votre système, qui fournit des points d'intégration avec d'autres services externes (c'est-à-dire une base de données), mais encore une fois, je ne pense pas que ce soit ce dont vous parlez ici. Donc, je pourrais m'en tenir à l'approche de l'encapsulation de la logique dans la classe File elle-même.