Comment concevez-vous un système de livraison dorne du point de vue de l'architecture logicielle?

Question

Pour mon projet final de maîtrise, j'ai décidé de concevoir un système de livraison de drones. L'objectif principal est d'apprendre à concevoir des systèmes complexes.

Le cas d'utilisation de base est la suivante:

1. utilisateur va à la boutique de marchand en ligne, sélectionne les produits, sélectionne la méthode de livraison que « la livraison de Drone » et choisit son lieu de livraison.
2. Site marchand, effectue un appel d'API à notre application de système de livraison de drones (DDS) pour enregistrer le nouveau bon de livraison (la commande contiendra toutes les informations dont nous avons besoin: emplacement de ramassage et lieu de destination ...)
3. L'application DDS basée sur les positions des drones, et basée sur un algorithme va calculer et marquer quel drone peut livrer cet ordre dans les plus brefs délais.
4. Le drone sélectionné, lorsqu'il est libre, livrera la commande.

Jusqu'ici tout va bien. Mes questions sont liées à l'architecture logicielle de ce système. J'ai quelques questions générales et quelques questions spécifiques.

Questions générales:

• Comment concevoir un système comme celui-ci afin d'être évolutive? Je veux dire: Le système peut être utilisé par les commerçants may, s'ils touchent mon API en même temps avec 100 commandes, le système doit être capable de le gérer.
• Quels sont les bons principes ou modèles de conception lors de la conception d'un système comme celui-ci?

Questions spécifiques:
i ont jusqu'à présent est venu avec cette architecture:

Composants du système:

1. application Java (Spring)
   • Rest web servce
   • interface web gérant dorens et parces
   • bussines logique et des algorithmes pour les drones de routage
   • producteur/consommateur pour
   RabbitMQ
2. Mysql serveur
3. rabbitmq
   

flux système:

1. Merchant hits API REST pour enregistrer la commande
2. L'application Java enregistre l'ordre dans la base de données Mysql.
3. Après avoir enregistré la commande dans la base de données, un producteur place la commande dans une file d'attente dans RabbitMQ
4. Un consommateur consomme la file d'attente de commandes RabbitMQ. Il prend chaque commande et calcule en fonction d'un algorithme le drone qui offre le meilleur temps pour la livraison. Chaque drone a une file d'attente séparée dans RabbitMQ. Après avoir trouvé le meilleur drone, le consommateur insère la commande dans la file d'attente du drone dans RabbitMQ. Le consommateur interroge également la base de données mysql au cours de ce processus.
5. Chaque fois qu'un drone est libre, il communiquera avec le système pour demander la prochaine commande. Le système va regarder dans la file d'attente du drone RabbitMQ et prendra de là la prochaine commande.

Mes questions sont liées au consommateur et producteur:

1. est OK que le consommateur ait une logique en elle, dans mon exemple, il aura l'algorithme qui déterminera le meilleur drone , pour ce faire, il faut aussi parler à mysql, pour récupérer des positions de drones? Est-ce une bonne pratique? Si non, comment puis-je faire différemment?

2. La meilleure pratique pour le consommateur de rester dans l'application? À l'heure actuelle, les consommateurs utilisent le même serveur que le service Web et le code n'est pas séparé du code de service Web. Je pense que peut-être à l'avenir, vous devrez déplacer les consommateurs dans un serveur séparé? Comment pensez-vous que les consommateurs peuvent facilement être séparés de l'application?

3. Je pense que le producteur doit rester dans l'application, je veux dire est couplé avec l'application de service Web. Est-ce que c'est OK?

Désolé pour le poste long, et pour mon pauvre anglais. Merci beaucoup :)

Answer 1

Oui, le consommateur devrait avoir de la logique dedans. Ceci est une norme EIP routing pattern. Si vous séparez correctement vos couches logiques métier de vos couches d'accès aux données (votre accès aux files d'attente est une couche d'accès aux données), il n'est probablement pas problématique de les partager toutes dans un projet commun. En fin de compte, vous voulez probablement séparer votre logique d'entreprise/votre modèle de domaine du service Web et du routeur/consommateur, mais ce sont beaucoup plus des problèmes de déploiement et d'empaquetage. Tant que vous gardez votre code de service Web hors de votre logique métier (et vice versa), vous serez probablement bien, vous devrez simplement déployer le tout plusieurs fois, et exposer uniquement les points finaux qui sont pertinents pour tout déploiement donné. En fin de compte, vous serez peut-être plus heureux si vous séparez vos couches par le biais de bibliothèques, car cela ne fera qu'aggraver les problèmes.

Et oui, le producteur doit être déployé avec le service Web, assurez-vous simplement que vous êtes conscient que, en tant que couche d'accès aux données, c'est dans un package/classe distinct. Cela rendra vos tests beaucoup plus faciles.