Temps estimé: 20 minutes
Série d'exercices sur l'architecture et les contextes
Question 1
Tout au long de la session, il a souvent été question de domaine riche vs CRUD, expliquez donc dans vos mots votre compréhension de ces deux contextes.
CRUD: comme son nom l'indique, on parle ici d'un contexte où il est principalement question des opérations de stockage de données (create, read, update, delete) et où il n'y a pas (ou très peu) de logique d'affaires. Donc, le contexte veut que les données sont extraites et immédiatement retournées pour fins d'affichage. L'affichage est généralement très proche de la représentation en BD.
Alors que pour un domaine riche, nous ne sommes pas centrés sur les données, mais plutôt sur les opérations, les cas d'utilisation et les règles d'affaires qui opèrent sur ces données. Généralement, les points d'entrées & sorties sont très petits, très simples en comparaison avec la quantité de règles d'affaires.
Question 2
Pourquoi est-ce important de connaître et comprendre le contexte dans lequel on se trouve?
Entre autres car chaque contexte possède ses propres enjeux. Il faut donc appliquer les bons patterns pour ne pas complexifier le design inutilement ou à l'inverse, pour ne pas créer des problèmes de maintenabilité.
Question 3
Selon le contexte suivant: Les données affichées sont naturellement reliées à la représentation dans la base de données et il n'y a pas de logique d'affaires.
Que pensez-vous du code suivant:
public class CarResource {
@GET()
@Path("/{carId}")
public CarDTO getCar (@PathParam("carId") String carId) {
Car car = carService.getCarBy(carId);
return carAssembler.assembleFrom(car);
}
}
public class CarAssembler {
public CarDTO assembleFrom (Car car) {
return new CarDTO(car);
}
}
public class CarService {
public Car getCar (String carId) {
return carRepository.getCarBy(carId);
}
}
public class CarRepository {
public Car getCar (String carId) {
...
}
}On peut constater qu'il y a de la délégation inutile. Chaque couche n'apporte rien et ne protège pas pour d'éventuels changements. En effet, sachant que l'affichage est lié à la représentation dans la base de données, si cette dernière change, l'affichage changera de toute manière et toutes les couches qu'on aurait pu rajouter.
Question 4
Nommez quelques points qu'un design dans du CRUD peut avoir qu'il ne faudrait pas qu'un design dans un domaine riche possède.
Contrairement à un domaine riche, il est approprié qu'un domaine CRUD ne contienne pratiquement que des getters et des setters, car peu ou pas de logique d'affaires n'est requise. Si les données affichées sont intimement liées à la manière dont elles sont stockées, certaines couches peuvent ne pas être nécessaires comme mentionné à la question précédente car le cycle de changement est le même.
De plus, le modèle de données pourrait être le même (selon le contexte) que celui retourné pour des fins d'affichage sans ajouter de couches de transformation (et de protection).
Question 5
Résumez votre compréhension de ce que signifie le terme "ubiquitous language" (voir: https://martinfowler.com/bliki/UbiquitousLanguage.html)
Le terme "ubiquitous language" est utilisé lorsque nous sommes dans un domaine complexe pour décrire le vocabulaire d'un contexte précis. Dicté par le besoin d'affaires, il s'agit d'un langage commun partagé entre les développeurs et l'équipe business.
Exemple: Dans une compagnie comme Netflix, même si vous êtes la même personne physique, vous pourriez représenter des acteurs différents (vocabulaires différents) dans les différents contextes du produit. Dans le contexte des abonnements, vous pourriez être considéré comme un-e abonné-e, alors que dans le contexte de la diffusion web (streaming), vous pourriez être considéré comme un-e spectacteur-rice.
On peut donc retrouver un Ubiquitous Language par contexte d'affaires au sein d'une même compagnie.