En bref : Que doit faire un architecte ?

Cet article est une nouvelle qui imite les Q&R, et l’auteur utilise un style humoristique pour analyser brièvement le travail des architectes : Je veux devenir architecte logiciel.

C’est une excellente option pour les jeunes développeurs logiciels.

Je veux diriger l’équipe et prendre des décisions importantes concernant les bases de données et frameworks, les serveurs web, etc.

Ah, alors tu ne veux pas du tout être architecte logiciel.

Bien sûr, je voulais être le preneur des décisions importantes.

C’est très bien, mais vous n’incluez pas les décisions importantes dans votre liste, qui sont des décisions sans importance.

Que veux-tu dire? Voulez-vous dire que les bases de données ne sont pas des décisions importantes, savez-vous combien nous dépensons pour elles ?

Peut-être que ça coûte trop cher. Cependant, les bases de données ne sont pas l’une des décisions importantes.

Comment peux-tu dire ça ? La base de données est le cœur du système, où toutes les données sont systématisées, classifiées, indexées et consultées. Sans base de données, il n’y aurait pas de système.

La base de données n’est qu’un dispositif d’E/S qui fournit des outils utiles pour la classification, l’interrogation et le reporting d’informations, mais ce ne sont que des fonctions auxiliaires de l’architecture système.

De l’aide ? C’est scandaleux.

C’est ça, c’est auxiliaire. Les règles métier du système peuvent tirer parti de certains de ces outils, mais ces outils ne sont pas inhérents aux règles métier correspondantes. Si besoin, vous pouvez remplacer les outils existants par d’autres outils ; Et les règles métier ne changeront pas.

Eh bien, oui, mais il a fallu le recoder, car ces outils étaient utilisés dans la base de données originale.

C’est ton problème.

Que veux-tu dire?

Votre problème, c’est que vous pensez que les règles métier dépendent des outils de base de données, mais ce n’est pas le cas. Ou du moins, cela ne devrait pas être ainsi tant qu’une bonne architecture n’est pas fournie.

C’est juste fou. Comment créer des règles métier qui n’utilisent pas ces outils ?

Je ne dis pas qu’ils n’utilisent pas d’outils de base de données, mais ils n’en dépendent pas. Les règles métier n’ont pas besoin de savoir quelle base de données vous utilisez.

Alors, comment obtenir des règles métier sans savoir quels outils utiliser ?

Inversez les dépendances pour que la base de données dépende des règles métier. Assurez-vous que les règles métier ne dépendent pas de la base de données.

Tu dis n’importe quoi.

Au contraire, j’utilise le langage de l’architecture logicielle. C’est le principe d’inversion de dépendance : les normes de bas niveau devraient s’appuyer sur des normes de haut niveau.

N’importe quoi ! Critères de haut niveau (en supposant qu’il s’agit de règles métier) : Appel de critères de bas niveau (en supposant référence à des bases de données). Par conséquent, le critère de haut niveau s’appuiera sur le critère de bas niveau selon le principe que l’appelant dépend de l’appelant. Tout le monde le sait !

C’est vrai à l’époque. Mais lors de la compilation, ce que nous voulons, c’est une inversion de dépendance. Le code source des directives de haut niveau ne doit pas mentionner le code source des directives de bas niveau.

Allez! Comment peux-tu passer un appel sans en parler ?

Bien sûr, pas de problème. C’est ce que l’orienté objet implique.

L’orientation objet consiste à créer des modèles dans le monde réel, combinant données, fonctionnalités et objets cohérents. Il s’agit d’organiser le code dans une structure intuitive.

C’est ce qu’on dit ?

Comme nous le savons tous, c’est la vérité évidente.

Oui, c’est le cas, cependant, lorsqu’on utilise des directives orientées objet, il est effectivement possible d’invoquer sans en parler sans en parler.

Comment faire ?

Dans la conception orientée objet, les objets s’envoient des messages.

C’est exact, bien sûr.

Lorsqu’un expéditeur envoie un message, il ne connaît pas le type de destinataire.

Cela dépend du langage utilisé. En Java, l’émetteur connaît au moins le type de base du destinataire. Dans Ruby, l’émetteur sait au moins que le récepteur est capable de traiter les messages reçus.

C’est juste. Dans tous les cas, cependant, l’émetteur ne connaît pas le type spécifique de récepteur.

C’est vrai, eh bien, c’est vrai.

Ainsi, un émetteur peut concevoir un récepteur pour accomplir une fonction sans mentionner le type spécifique de récepteur.

C’est ça, c’est ça. Je comprends. Cependant, l’émetteur dépend toujours du destinataire.

C’est vrai à l’époque. Cependant, il est différent une fois compilé. Le code source de l’émetteur ne mentionne pas et ne dépend pas du code source du récepteur. En fait, le code source du récepteur dépend du code source de l’expéditeur.

Pas question! L’expéditeur dépend toujours de la classe qu’il envoie.

Peut-être qu’à partir d’un code source, cela sera plus clair. Le paragraphe suivant est écrit en Java. Tout d’abord, il y a l’expéditeur :

Voici le récepteur :

Note : Le destinataire dépend de l’expéditeur, SpecificReceiver dépend de l’expéditeur, et il n’y a aucune information liée au récepteur dans l’expéditeur.

Oui, mais tu mens, tu as mis l’interface du récepteur dans la classe de l’émetteur.

Tu commences à comprendre.

Qu’est-ce que tu sais ?

Bien sûr, c’est le principe de l’architecture. L’émetteur dispose de l’interface que le récepteur doit implémenter.

Si cela signifie que je dois utiliser des classes imbriquées, alors ......

Les classes imbriquées ne sont qu’un moyen d’atteindre une fin, il y a d’autres moyens.

Eh bien, attends une minute. Quel rapport cela a-t-il avec les bases de données ? Nous avons commencé à parler de bases de données.

Jetons un peu plus d’œil au code. La première est une règle simple :

Les règles métier n’ont pas beaucoup de poids.

Ce n’est qu’un exemple. Il pourrait y avoir d’autres classes de ce type qui implémentent de nombreuses règles métier différentes.

D’accord, qu’est-ce que Gateway exactement ?

Il fournit toutes les méthodes d’accès aux données via des règles métier. Implémentez-le comme suit :

Note : ceci est dans businessRules.

D’accord, c’est quoi le cours Quelque chose ?

Il représente un objet commercial simple. Je l’ai mis en entités.

En fin de compte, l’implémentation de BusinessRuleGateway, cette classe connaît la véritable base de données :

De plus, notez que les règles métier appellent la base de données à l’exécution ; Cependant, au moment de la compilation, la base de données implique et dépend des businessRules.

Eh bien, je crois que je comprends. Vous utilisez simplement le polymorphisme pour cacher le fait que la base de données est implémentée aux règles métier. Cependant, une interface reste nécessaire pour fournir tous les outils de base de données aux règles métier.

Non, pas du tout. Nous n’avons pas tenté de fournir des outils de base de données aux règles métier. À la place, ils utilisent des règles métier pour créer des interfaces adaptées à leurs besoins. Mettre en place ces interfaces vous permet d’appeler les bons outils.

Oui, mais si vous devez utiliser tous les outils pour toutes les règles métier, alors il suffit de mettre l’outil dans l’interface de la passerelle.

Ah, je ne pense pas que tu comprennes encore.

Comprendre quoi ? C’est déjà clair.

Chaque règle métier définit une seule interface pour les outils d’accès aux données dont elle a besoin.

Attends une minute, qu’en dis-tu ?

C’est le principe de ségrégation de l’interface. Chaque classe de règles métier utilise uniquement certaines fonctionnalités de la base de données. Par conséquent, les interfaces fournies par chaque règle métier ne peuvent accéder qu’aux fonctionnalités correspondantes.

Cependant, cela signifie qu’il existe de nombreuses interfaces et de nombreuses petites classes d’implémentation qui appellent d’autres classes de bases de données.

Super, tu commences à comprendre.

Mais c’est trop désordonné et une perte de temps. Pourquoi faire ça ?

C’est organisé et ça fait gagner du temps.

Allez, prenez beaucoup de code pour le principe.

Au contraire, des décisions non pertinentes peuvent être retardées par des décisions architecturales importantes.

Que cela signifie-t-il?

Je me souviens qu’au début, tu disais que tu voulais devenir architecte logiciel, non ? Vous voulez prendre toutes les décisions qui comptent vraiment.

Oui, c’est ce que je pensais.

Vous voulez prendre des décisions concernant les bases de données, les serveurs web et les frameworks, n’est-ce pas ?

Oui, tu dis que tout cela n’a aucune importance. Juste du contenu sans importance.

C’est juste. Voilà. Les décisions importantes prises par les architectes logiciels sont celles qui vous permettent de prendre des décisions concernant les bases de données, les serveurs web et les frameworks.

Mais il faut d’abord décider lesquelles !

Non, ça ne marche pas. En fait, ces éléments peuvent être décidés plus tard dans le cycle de développement, lorsque l’information est plus abondante.

C’est un désastre si les architectes identifient à l’avance des frameworks pour découvrir qu’ils n’offrent pas les performances requises ou introduisent des contraintes intolérables.

Ce n’est que lorsque l’architecte décide de reporter la décision qu’il prendra une décision lorsque l’information est suffisante ; Les équipes qui n’utilisent pas d’appareils et de frameworks d’E/S lents et gourmands en ressources peuvent créer des environnements de test rapides et légers à la discrétion des architectes. Seuls ses architectes se soucient de ce qui compte vraiment et retardent ceux qui ne comptent pas, et une telle équipe est la chanceuse.

N’importe quoi, je ne comprends pas du tout ce que tu veux dire.

Eh bien, regardez bien cet article, sinon vous devrez attendre encore 10 ans pour le comprendre.