26 août 2016

Domain Driven Design Part 3 - La conception collaborative

Design & Code

Dr. Ruijing

HU

Image d'une équipe.

26 août 2016

Domain Driven Design Part 3 - La conception collaborative

Design & Code

Dr. Ruijing

HU

Image d'une équipe.

26 août 2016

Domain Driven Design Part 3 - La conception collaborative

Design & Code

Dr. Ruijing

HU

Image d'une équipe.

Dans les précédents articles [6, 7], nous avons présenté les outils et les principes du Domain Driven Design (DDD). Cette fois, nous allons continuer l’Odyssée sur la mise en œuvre de la conception collaborative par des exemples codés en Python.

Le Domain Driven Design (DDD) met l'accent sur l'importance de la collaboration entre les développeurs, les analystes commerciaux et les autres parties prenantes dans le processus de développement logiciel. En travaillant ensemble, ils peuvent créer un modèle de domaine qui reflète avec précision les besoins du métier.

Le DDD invite à réviser la carte de contexte [7] pour analyser les liaisons en fonction de l’ouverture et la fermeture des contextes bornés.

1. Service Hôte Ouvert

Le service hôte ouvert (Open Host Service en anglais) est utilisé d'exposer le système externe en tant que service au modèle de domaine, plutôt que d'essayer de l'incorporer directement dans le domaine.

Supposons que nous ayons deux contextes bornés dans notre système de commerce électronique : la gestion des commandes et la gestion des clients. Le contexte borné Order Management est responsable de la gestion des commandes, tandis que le contexte borné Customer Management est responsable de la gestion des clients.

Nous voulons créer un Open Host Service qui permet au contexte borné Order Management d'accéder aux données du contexte borné Customer Management. Par ailleurs, nous allons profiter du module « dataclass » en Python 3.7+ qui fournit un moyen pratique de créer des classes avec des méthodes spéciales générées automatiquement, telles que __init__, __repr__ et __eq__.

from dataclasses import dataclass
from typing import List
# In the Customer Management bounded context
@dataclass
class Customer:
    id: str
    name: str
    email: str
class CustomerRepository:
    def __init__(self):
        self.customers = []
    def find_by_id(self, id):
        # Find the customer by id
        for customer in self.customers:
            if customer.id == id:
                return customer
        return None
# In the Order Management bounded context
@dataclass
class OrderItem:
    product_name: str
    quantity: int
@dataclass
class Order:
    customer_id: str
    items: List[OrderItem]
class OrderService:
    def __init__(self, customer_service):
        self.customer_service = customer_service
    def create_order(self, customer_id, items):
        # Use the customer service to get the customer information
        customer = self.customer_service.get_customer(customer_id)
        # Create the order
        order = Order(customer.id, items)
        # Save the order
        # to do
        return order
# The Open Host Service
class CustomerService:
    def __init__(self, customer_repository):
        self.customer_repository = customer_repository
    def get_customer(self, customer_id):
        # Find the customer by id
        customer = self.customer_repository.find_by_id(customer_id)
        if customer is None:
            raise ValueError("Client non trouvé")
        return customer
if __name__ == '__main__':
    # create some customers
    customer1 = Customer(1, 'Léa Lee', 'lea.lee@invivoo.com')
    customer2 = Customer(2, 'Léo Hu', 'leo.hu@invivoo.com')
    # add customers to the customer repository
    customer_repository = CustomerRepository()
    customer_repository.customers = [customer1, customer2]
    # create a customer service using the customer repository
    customer_service = CustomerService(customer_repository)
    # create an order service using the customer service
    order_service = OrderService(customer_service)
    # create an order for customer 1
    items = [OrderItem('jeans', 2), OrderItem('baskets', 5)]

Dans cet exemple, le contexte borné Customer Management expose un CustomerService qui permet au contexte borné Order Management d'accéder aux données de client. Le CustomerService prend un CustomerRepository comme dépendance, ce qui lui permet d'accéder aux données de client.

OrderService dans le contexte borné de Order Management prend un CustomerService comme dépendance et l'utilise pour obtenir les informations de client lors de la création d'une commande.

Cette implémentation d'un service d'hôte ouvert dans DDD permet une séparation des préoccupations entre les deux contextes bornés et fournit un moyen clair et normalisé pour le contexte borné de gestion des commandes d'accéder aux données du contexte borné de gestion des clients.


2. Noyau partagé 

Le noyau partagé (Shared Kernel en anglais) est une relation entre deux ou plusieurs contextes bornés qui partagent une base de code ou un schéma de base de données commun.


Supposons que notre système de commerce électronique a deux contextes bornés, Product et Order. Dans le contexte Product, nous avons une entité Product qui possède des propriétés telles que le nom, la description et le prix. Dans le contexte Order, nous avons une entité Order qui possède des propriétés telles que customer, items et total_price.

Pour partager l'entité Product entre les deux contextes, nous pouvons définir l'entité Product dans un module partagé.

 shared_kernel.py
from dataclasses import dataclass
from typing import List, Optional
@dataclass
class Product:
    id: int
    name: str
    description: str
    price: float
class OrderItem:
    def __init__

Désormais, dans les contextes bornés Order Management et Inventory Management, nous pouvons importer l'entité Product à partir du module partagé et l'utiliser au besoin.

Sinon, lorsqu'une classe de dataclass est créée, sa méthode __init__ est automatiquement générée en fonction des champs définis. Cependant, si vous souhaitez effectuer des opérations supplémentaires après l'initialisation de l'objet, vous pouvez définir la méthode __post_init__ dans la classe. En plus, elle ne prend aucun argument autre que self et peut accéder et modifier les attributs de l'objet selon les besoins. Elle sera appelée automatiquement par Python immédiatement après l'initialisation de l'objet.

 order_management.py
# In the Order Management context
from shared_kernel import Product
@dataclass
class Order:
    customer_id: int
    items: List[OrderItem]
    total_price: Optional[float] = None
    def __post_init__(self):
        self.total_price = sum([item.product.price * item.quantity for item in self.items])
    def add_item(self, product: Product, quantity: int):
        # Add a new item to the order
        item = OrderItem(product, quantity)
        self.items.append(item)
        # Recalculate the total price of the order
        self.total_price = sum([item.product.price * item.quantity for item in self.items])
# inventory_management.py
# In the Inventory Management context 
from shared_kernel import Product
class Inventory:
    def __init__(self):
        self.inventory: List[Product] = []
    def add_product(self, product: Product):
        # Add the product to the inventory
        self.inventory.append(product)
    def remove_product(self, product_name: str):
        # Check if the product is in the inventory
        for product in self.inventory:
            if product.name == product_name:
                # Remove the product from the inventory
                self.inventory.remove(product)
                return True
        return False
if __name__ == "__main__":
    # Create some example products
    product1 = Product(1, "CD Céline Dion", "Titanic", 30.0)
    product2 = Product(2, "Ticket Astérix ", "Astérix Attraction", 20.0)
    product3 = Product(3, "Guide Paris", "Guide Voyage", 10.0)
    # Create an example order
    order = Order(1, [OrderItem(product1, 2), OrderItem(product2, 1)]


De cette façon, toute modification apportée à l'entité Product dans le module partagé sera automatiquement répercutée dans les contextes Order et Inventory, garantissant la cohérence et évitant la duplication de code.

3. Client-fournisseur

Le client-fournisseur (Customer Supplier Teams en anglais) est une relation entre deux ou plusieurs contextes bornés où un contexte fournit un service ou des données à un autre contexte. Le contexte fournisseur est le fournisseur et le contexte récepteur est le client.

En e-commerce, l'équipe client serait responsable de la définition des exigences et des règles commerciales liées aux informations sur les produits et leurs stocks. Ils travailleraient en étroite collaboration avec l'équipe du fournisseur, qui serait l’inventaire qui gère les stocks de produits, y compris l’ajout et la suppression des données.

from dataclasses import dataclass
from typing import List
@dataclass
class Product:
    id: int
    name: str
    description: str
    price: float
# Inventory Management Bounded Context
@dataclass
class Inventory:
    products: List[Product]
    def add_product(self, product: Product):
        self.products.append(product)
    def remove_product(self, product: Product):
        self.products.remove(product)
# Order Management Bounded Context
@dataclass
class Order:
    id: int
    customer_id: int
    items: List[Product]
@dataclass
class OrderService:
    inventory: Inventory
    def place_order(self, order: Order):
        for item in order.items:
            if item not in self.inventory.products:
                raise ValueError(f"Product {item.name} is not in inventory.")
        # Place the order...
if __name__ == '__main__':
    # Create some sample data
    product1 = Product(1, "CD Céline Dion", "Titanic", 30.0)
    product2 = Product(2, "Ticket Astérix ", "Astérix Attraction", 20.0)
    product3 = Product(3, "Guide Paris", "Guide Voyage", 10.0)
    inventory = Inventory([product1, product2, product3])
    order = Order(1, 1, [product1, product1, product3]

Dans cet exemple, le contexte Inventory Management définit la classe de données Inventory, qui gère une liste de produits, tandis que le contexte Order Management définit la classe de données Order et la classe OrderService, qui place les commandes. OrderService dépend de l'inventaire du contexte de gestion des stocks.

Dans cette relation, le service de commande est le client, qui dépend du fournisseur : l'inventaire pour vérifier si les articles d'une commande sont en stock avant de placer la commande.

En utilisant cette approche, l'équipe du client est en mesure de définir et de gérer sa logique de domaine séparément du fournisseur en amont, ce qui permet une plus grande flexibilité et une maintenabilité à long terme.

4. Conformiste 

Le conformiste (Conformist en anglais) donne les conventions et les règles d'un autre contexte que le contexte conformiste suit en ajustant son comportement pour correspondre aux exigences du contexte dirigeant.

Supposons que nous ayons un contexte borné : Rating Management pour gérer les évaluations de produits. Ce contexte est responsable de la gestion des notes et des avis des clients pour chaque produit. Les évaluations sont stockées dans une base de données et peuvent être consultées par d'autres contextes bornés dans le système.

Du fait, dans un autre contexte borné responsable de la gestion des recommandations de produits, les données d'évaluation ne sont pas stockées dans le format requis pour des calculs de recommandation efficaces. Afin d'utiliser les données de notation dans ce contexte, nous devons les transformer dans le format correct.

C'est là que le modèle conformiste entre en jeu. The Conformist est une classe qui convertit les données d'un format à un autre.

Voici un exemple d'implémentation :

from dataclasses import dataclass
from typing import List
@dataclass
class Product:
    id: int
    name: str
    description: str
    price: float
# Rating Management bounded context
@dataclass
class Rating:
    customer_id: int
    product_id: int
    rating: int
    review: str
class RatingConformist:
    def __init__(self, ratings: List[Rating]):
        self.ratings = ratings
    def get_ratings_by_product(self, product_id: int) -> List[int]:
        return [rating.rating for rating in self.ratings if rating.product_id == product_id]
# In the Product Recommendations bounded context
class ProductRecommendations:
    def __init__(self, ratings_conformist: RatingConformist):
        self.ratings_conformist = ratings_conformist
    def get_recommendations(self, product_id: int) -> List[Product]:
    # Get the ratings for the product using the RatingConformist
      product_ratings = self.ratings_conformist.get_ratings_by_product(product_id)
      # Get a list of all products that have been rated, except for the current product
      rated_products = set(r.product_id for r in self.ratings_conformist.ratings if r.product_id != product_id)
      # Calculate the average rating for each rated product and store the results in a list of tuples
      avg_ratings = [(product_id, sum(self.ratings_conformist.get_ratings_by_product(product_id)) / len(self.ratings_conformist.get_ratings_by_product(product_id)))
                     for product_id in rated_products]
      # Sort the list of tuples by average rating and get the best products
      top_products = sorted(avg_ratings, key=lambda x: x[1], reverse=True)[:1]
      # Get the recommended products based on the top product IDs
      recommended_products = [p for p in self.ratings_conformist.ratings if p.product_id in [tp[0] for tp in top_products]]
      # Return the recommended products
      return recommended_products
if __name__ == "__main__":
    # In the Rating Management bounded context
    ratings = [
        Rating(customer_id=1, product_id=1, rating=4, review="Good product"),
        Rating(customer_id=2, product_id=1, rating=5, review="Great product"),
        Rating(customer_id=3, product_id=1, rating=3, review="Okay product"),
        Rating(customer_id=1, product_id=2, rating=5, review="Awesome product"),
        Rating(customer_id=2, product_id=2, rating=4, review="Very good product"),
        Rating(customer_id=3, product_id=2, rating=4, review="Great product"),
        Rating(customer_id=1, product_id=3, rating=2, review="Not so good product"),
        Rating(customer_id=2, product_id=3, rating=3, review="Average product"),
        Rating(customer_id=3, product_id=3, rating=2, review="Disappointing product")
    ]


Dans cet exemple, nous obtenons un ensemble de tous les produits notés (à l'exclusion du produit actuel), puis calculons la note moyenne pour chaque produit noté dans une compréhension de liste qui crée une liste de tuples. La liste des tuples est ensuite triée par note moyenne et les meilleurs produits sont sélectionnés. Enfin, les produits recommandés sont obtenus à l'aide d'une liste en compréhension et renvoyés.

5. Couche anti-corruption (ACL) 

La couche anti-corruption (Anti-corruption Layer en anglais) joue le rôle du pont entre les contextes ayant les incohérences des attributs, traduisant et validant les données échangées entre eux.

Disons que nous avons deux contextes bornés : Sales et Shipping. Le contexte Sales a une entité SalesCustomer qui a un nom et une adresse, tandis que le contexte Shipping a une entité ShippingCustomer similaire avec un nom et une adresse de livraison. Cependant, les deux contextes utilisent des termes différents pour désigner le même concept – « adresse de facturation » dans Sales et « adresse de livraison » dans Shipping. Pour éviter la confusion et les incohérences, nous pouvons utiliser une couche anti-corruption pour traduire entre les deux contextes.

Voici le code de la couche anti-corruption :

from dataclasses import dataclass
# In the Sales context
@dataclass
class SalesCustomer:
    name: str
    billing_address: Address
@dataclass
class Address:
    street: str
    city: str
    country: str
    zip_code: str
# In the Shipping context
@dataclass
class ShippingCustomer:
    name: str
    shipping_address: Address
# In the Anti-corruption Layer
class SalesToShippingTranslator:
    def translate_customer(self, customer):
        shipping_address = Address(
            street=customer.billing_address.street,
            city=customer.billing_address.city,
            country=customer.billing_address.country,
            zip_code=customer.billing_address.zip_code
        )
        translated_customer = ShippingCustomer(
            name=customer.name,
            shipping_address=shipping_address
        )
        return translated_customer
class ShippingService:
    def create_shipping_order(self, customer):
        print(f"Creating shipping order for customer {customer.name} with address {customer.shipping_address.street}, {customer.shipping_address.city}, {customer.shipping_address.country}, {customer.shipping_address.zip_code}")
if __name__ == "__main__

Dans cet exemple, lorsque le contexte Sales doit envoyer une entité SalesCustomer au contexte Shipping, il peut utiliser le SalesToShippingTranslator pour traduire l'entité Customer en une entité ShippingCustomer.

De cette façon, les deux contextes peuvent communiquer sans dupliquer le code ni causer de confusion.


6. Chemins séparés 

Les Chemins séparés (Separate Ways en anglais) est la séparation des préoccupations par la décomposition d’un package ou un module monolithe en domaines ou sous-domaines distincts et bien définis.

Disons que nous avons un site Web de commerce électronique qui vend à la fois des produits physiques et numériques. Nous avons une classe Product qui représente les deux types de produits. Cependant, lorsque nous voulons traiter une commande, nous devons traiter différemment les produits physiques et numériques.

Pour appliquer le modèle Separate Ways, nous pouvons diviser la classe Product en deux classes distinctes : PhysicalProduct et DigitalProduct. Chaque classe peut avoir son propre ensemble d'attributs et de méthodes spécifiques au type de produit qu'elle représente.

from dataclasses import dataclass
@dataclass
class Address:
    street: str
    city: str
    zipcode: str
    country: str
@dataclass
class Customer:
    name: str
    email: str
    shipping_address: Address
@dataclass
class Product:
    name: str
    price: float
    sku: str
    def process_order(self, customer):
        if isinstance(self, PhysicalProduct):
            shipping_address = customer.shipping_address
            print(f"Creating shipping order for product {self.name} to customer {customer.name} with shipping address {shipping_address}")
            print(f"Processing payment for customer {customer.name} for amount {self.price}")
        elif isinstance(self, DigitalProduct):
            print(f"Sending download link for product {self.name} to customer {customer.name} at email address {customer.email}")
            print(f"Processing payment for customer {customer.name} for amount {self.price}")
@dataclass
class PhysicalProduct(Product):
    weight: float
@dataclass
class DigitalProduct(Product):
    download_url: str
if __name__ == "__main__

Dans cet exemple, on crée une instance Customer avec son objet Adresse et deux instances de produit : PhysicalProduct et une DigitalProduct. Ensuite, il appelle la méthode process_order sur chaque instance de produit, en transmettant l'instance Customer. La logique de traitement de commande appropriée est exécutée en fonction du type de produit.

Du coup, le contexte PhysicalProduct et le contexte DigitalProduct peuvent être développés et déployés indépendamment.  


Conclusion

Dans cet article, nous avons bien démarré les épreuve sur les pratiques de la conception collaborative en Python, tout en révisant la carte de contexte dans la conception pilotée par le domaine (DDD). En suivant ces pratiques, les développeurs peuvent créer des systèmes logiciels bien conçus, efficaces et faciles à maintenir.


Références

  • Evans, E. (2003). Domain-driven design: tackling complexity in the heart of software. Addison-Wesley Professional.

  • Vernon, V. (2011). Implementing domain-driven design. Addison-Wesley Professional.

  • Fowler, M. (2013). Patterns of enterprise application architecture. Addison-Wesley Professional.

  • Ghosh, S. (2016). Domain-driven design: A practical approach. Packt Publishing.

  • Larman, C. (2004). Applying UML and patterns: an introduction to object-oriented analysis and design and iterative development. Prentice Hall PTR.

  • L’article de la Conception Pilotée par Domain (1)

  • L’article de la Conception Pilotée par Domain (2)