Je suis dans la startup depuis l'année dernière et je développe avec le framework Python Django. Il y avait un développement vierge pendant près de cinq ans, alors j'ai décidé d'être optimiste, "Est-ce le développement d'aujourd'hui?" Cependant, il était plein de divers anti-motifs et points de plongée.
L'ancien responsable et le responsable précédent ont cessé et l'attachement a été inversé. En regardant le code laissé derrière, je ne peux pas m'empêcher d'y penser.
Dans de telles circonstances, je voudrais résumer l'histoire du refactoring et l'histoire du refactoring à partir de maintenant.
Il semble que cela ne s'arrêtera pas quand je commencerai à parler, mais il y avait deux choses décevantes en termes d'architecture.
Il semble que ce soit une application simple dont la vue ne récupère que les données créées à l'origine par le traitement par lots. Cependant, avec l'ajout de fonctions, divers calculs sont désormais effectués dans la vue.
Il semble que la personne précédente ait essayé de faire quelque chose, mais la logique est restée dans la vue et le modèle avait une logique. Vous pouvez générer des références circulaires dans deux packages différents. Je n'ai pas confirmé l'opération. Ça a été terrible.
J'ai mis de côté le fait que je n'avais pas assez de temps, ~~ le responsable était stupide ~~, et cela dépend de la situation et des gens.
En premier lieu, Django suppose une configuration simple avec une table et un modèle 1: 1. C'est un peu différent de la signification originale, mais c'est probablement le modèle Active Record.
Cette configuration devient problématique à mesure que l'application devient plus complexe.
À mesure que la fonctionnalité devient plus complexe, la table change. Il peut ne pas correspondre au modèle que vous attendiez à l'origine.
Avec Django, vous avez tendance à appeler le modèle directement depuis la vue.
Lorsque vous combinez des informations provenant de plusieurs tables, vous avez tendance à écrire une logique dans la vue. Si vous faites des calculs compliqués, il sera difficile de comprendre où se situe la responsabilité, en vous demandant: "Quoi? Ce modèle est-il responsable?"
Model-View-Controller est un modèle de couche de présentation en premier lieu. Il semble que le modèle soit mélangé avec le modèle architectural de la source de données, ce qui prête à confusion. (Je pense que je ne comprends tout simplement pas)
Je suis retourné à l'essentiel et j'ai commencé par superposer. À ce moment-là, j'ai fait référence à la conception axée sur le domaine et au modèle d'architecture d'entreprise (bien qu'il ait une mauvaise réputation).
Personnellement, j'en avais marre du contenu du modèle d'architecture d'entreprise.
http://www.amazon.co.jp/dp/4798121967 http://www.amazon.co.jp/dp/4798105538
Il y a quelques motifs, mais il était facile de comprendre comment les diviser en 4 couches.
Encore une fois, ce qui rendait Django personnellement déroutant, c'est qu'il semblait que le modèle de couche de présentation, la couche de domaine et la couche de données étaient tous en un. C'est devenu une clé pour diviser cette zone.
Modifié pour fournir un service pour une vue. Je ne veux pas que les paramètres de méthode soient compliqués, je les laisse donc gérer les paramètres de type objet de transfert de données.
Le service est également divisé en deux types.
La première consiste à gérer le CRUD de base. La convention de dénomination est également XxxService.
L'autre consiste à combiner plusieurs objets pour effectuer des calculs et des traitements complexes. La convention de dénomination est également XxxEngine.
Je n'ai pas bien compris même si j'ai lu diverses explications, alors je me suis référé au code suivant. http://www.infoq.com/jp/news/2015/04/ddd-trading-example https://github.com/archfirst/bullsfirst-server-java
Il est également inefficace de créer une instance du service à chaque fois, donc je l'ai fait Singleton.
http://code.activestate.com/recipes/579090-yet-another-singleton-pattern-in-python-using-clas/
C'est un problème futur.
Il y avait des choses similaires dans XxxEngine. C'est une brume qui vous donne une meilleure vue si vous la séparez avec le modèle Stratégie.
J'ai décidé de considérer le modèle de Django comme une couche de données.
Dans le futur, je pense introduire une couche de domaine. Implémentez la logique de domaine dans une classe qui hérite du modèle de Django.
Autrefois, lors de la conversion d'une table en objet, il était mappé vers POJO (Plain Old Java Object). Pour implémenter la logique en tant que modèle de domaine, une classe héritant de POJO a été utilisée. Avec cela comme référence, je pense hériter de POMO (mon mot inventé w: Plain Old Model Object) et en faire un modèle de domaine.
J'ai toujours l'impression que c'est subtil, mais la situation actuelle est comme ça.
Quand j'ai vu l'histoire de l'introduction de la couche service dans Rails, j'ai pensé "Il y a des gens qui pensent la même chose", alors j'ai résumé ce que je pensais / correspondais dans Django.
Cependant, ce qui m'inquiétait cette fois, c'était le problème dont on parlait dans le modèle d'application d'entreprise. De nos jours, il y a beaucoup de choses que le framework cache et dont il n'est pas conscient. Mais quand j'essayais de repousser les limites du cadre, j'ai pensé qu'il était important de connaître les bases.
Recommended Posts