Domain Driven Design : partie 2

Dans la première partie on a vu à quoi servait le DDD, le nommage des classes, découper son projet en Bounded Context et comment les Aggregates peuvent séparer les responsabilités.

Comment faire pour éviter que notre projet ne se transforme en une usine à gaz ?

Si on avait une règle à retenir ça serait celle-ci :

Un cas d’utilisation = une transaction = un aggregate

Domain Driven Design : Partie 1

Domain Driven Design c’est essentiellement une question de nommage. On nomme énormément de choses dans notre code, mais de quelle manière ? et pourquoi ?

Pour ceux qui aiment la programmation orientée objet, on modélise très vite notre model en un diagramme de classe. On donne un nom générique à chaque classe et c’est plié.

Pourtant quand on commence un nouveau projet, on nous donne un contexte, un domaine sur lequel nous reposer. Si on doit proposer un catalogue de vélo ou de voyages, on va utiliser des mots et des termes différents. Cependant, notre code lui va rester sensiblement le même.

Automatisation de relance email, ne développez pas !

Dans le cadre de plusieurs projets, hors du pur développement technique, nos clients nous demandent de mettre en place la couche « Technique / Marketing ».
Voici quelques exemples :

  • Relancer une action non terminée
  • Solliciter un utilisateur qui n’a pas complètement rempli son profil à J+5
  • Envoyer une relance pour l’expiration de sa carte bleue tous les mois tant que cette CB n’est pas à jour

Formulaires Symfony pour modifier vos requêtes DQL

Le titre est un peu étrange mais dans la réalité ça fonctionne !

Les formulaires Symfony sont vraiment très simple à utiliser, sûrement le composant le plus enfantin qui soit !

Petite démonstration avec le LexikFormFilterBundle qui permets d’ajouter des conditions en DQL dans vos requêtes.
Prenons le cas d’un date range. On aimerait avoir un sélecteur qui nous affiche soit un champ date qui filtrerait les résultats avec une date >= ou alors le sélecteur nous propose de choisir entre une date de début et une date de fin.

LexikFrameworkAcceleratorBundle

Dans le milieu du web tout le monde a déjà été confronté à des clients qui veulent des pages toujours plus rapide, moins longue et surtout plus rapide. Lexik étant très attentif aux performances applicatives, nos équipes ont investi de longues années de R&D dans le but de mettre au point une technique d’optimisation.