Architecture d'un système
Méthodes d'architecture
Meet-up Arch Kata du 21/04/2018
http://nealford.com/katas/list.html
Parce que sans mèthodologie, on arrive à ... :
Des méthodes permettent de faire participer l'équipe à l'architecture du système.
La méthode des 4Cs :
Source : https://c4model.com/
Context
En haut : les users
En bas : Les systèmes externes avec lequel le système va interragir
Containers
Ensemble des containers qui composent le système
Components
Pour chaque containers, on peut zoomer pour y exposr les components
Classes
Diagramme de classe des components
Event storming
Source :
https://fr.slideshare.net/jeppec/event-storming-48594742
http://ziobrando.blogspot.fr/2013/11/introducing-event-storming.html
Permet d'approfondir l'attendu fonctionnel en raisonnant en terme d'événements :
3 types de post-it :
- Commande : Un verbe, Exemple : Parler
- Event : Un événément passé, exemple : A reçu un message
- Agregats : Un objet dont l'état est changé par un événement.
Exemple :
Architecture en APIs
Une architecture qui semble pertinente :
Autant d'API que de thème métier
Exemple du retail :
Pour chaque API, architecture "MC" sur un seul projet
Model :
- Ensemble de BOs correspondants au métier de l'API qui correspondent aux tables de la bdd.
- Ensemble de DTOs correspondants chacun à un BO. (n DTOs pour un BO). (un BO peut être un DTO)
- 3 tiers : (n) DAO - (1) Service (1) - [Sur le controller (1) WebService]
- DAO va appeler en base et fournir des Bos
- Service va appeler le DAO et me fournir des DTOs
- WebService exposé dans le controller va simplement appeler le service
Controller :
- Prend en charge les requêtes GET POST ... contenant les URL et appelle : Expose les webservice
View :
- Pas besoin de view : nothing to Json ou Json to better Json
Architecture Micro Service
Vocabulaire
Service : Un service métier : Un groupe de services techniques (REST, SOAP) qui fournissent une fonctionnalité qui a un sens métier.
Projet : Un projet de développement informatique sur l'ensemble de son cycle de vie. (Pas seulement sur sa phase Projet, avant son basculement en mode Maintenance).
Monolithe : Une grosse application qui gère l'UI / Component / Layers / Class. L'invers de l'architecture Micro-Service.
Source : https://www.c-sharpcorner.com/article/monolithic-application-design/
Celle-ci a l'avantage d'être facile à déployer, mais rencontre les problèmes de couplage verticaux (UI / Component / Layer / class) et horizontaux (entre plusieurs Component qui intéragissent)
Constat
Plus le projet est gros, plus il est difficile de le maintenir, de le faire évoluer sans effet de bord. Même si l'architecture logicielle est bonne, il apparaît avec le temps des rustines, les fonctionnalitées métier deviennent de plus en plus complexe.
L'architecture microservices
Pour éviter le problème des gros projets, il suffit de n'avoir que des petits projets : une réponse simple et radicale.
On limite donc la taille des projets à quelques personnes pour n'avoir que des Pizza teams d'une taille maximale de 7 personnes tout compris.
Il ne s’agit pas de séparer les gros projets en sous-équipes mais bien de projets indépendants : chacun a son organisation, son calendrier, sa base de code et ses donnée.
Les échanges entre les projets se font par des services. (REST / JSON).
On a beaucoup de petits projets, découpés en Petits domaines métiers, plutôt que des gros projets, découpés en gros domaines métiers.
Exemple de soundcloud :http://philcalcado.com/2015/09/08/how_we_ended_up_with_microservices.html