Be specific – We want to … – RulerZ

View Github Repository Open presentation in a new window

K-Phoen

See all presentation from K-Phoen

Be specific – We want to … – RulerZ

0 0

slides-forum-php-2015

Be Specific - Forum PHP 2015

On Github K-Phoen / slides-forum-php-2015

Be specific

Forum PHP 2015

Kévin Gomez / @KPhoen

Press [s] to read the speaker notes (will open a new window).

Application complexity keeps increasing

Depuis quelques années la complexité des applications web est à la hausse. Que ce soit côté frontend ou côté backend, nos applications et d'une manière générale les besoins auxquelles elles répondent sont de plus en plus complexes.

Languages / Tools / Design patterns / …

Pour répondre à cette tendance, les technologies que nous utilisons évoluent. On identifie des design patterns, on améliore nos langages de programmation et on développe de nombreux outils destinés à nous épauler dans nos tâches quotidiennes.

Agile / BDD / DDD / …

Et en parallèle de nos outils, nos méthodes évoluent. Souvent avec une mise en avant du comportement de l'application, du métier ou du domaine.

« Web applications » over « Websites »

« Business rules » over « Code »

De l'évolution des besoins découle une évolution des priorités et des manières de développer des applications. On ne parle d'ailleurs plus de "site web" mais "d'application web". De même, notre attention se porte plus particulièrement vers les aspects métier de notre projet, vers le domaine que l'on modélise et ses règles de fonctionnement. En tant que développeur, nous produisons de la valeur ajoutée en écrivant du code. Ou plus exactement en développant des outils destinés à répondre aux besoins de nos clients/utilisateurs. Mais au delà du code, un développeur produit le plus de valeur ajoutée quand il arrive, le plus fidèlement possible, à retranscrire dans l'application qu'il conçoit le coeur des règles métier de son client.

What should we do with these business rules?

On se rend compte qu'au delà des aspects purement techniques des applications web contemporaines se dégage une notion primordiale : celle du domaine métier et des règles qui le régissent. Ce sont finalement ces règles et cet univers qui sont complexes, passionnants et importants à modéliser. Mais ces règles, on en fait quoi dans nos applis ? Concrètement, en termes de code, de design patterns et autre, comment pouvons-nous les modéliser ?

We want to …

  • … understand them ;
  • … easily express them ;
  • … reuse them ;
  • … compose them.
Tout d'abord, fixons nous quelques objectifs quand à ces règles métier. En tant que développeur, je veux tout d'abord comprendre les règles qui me seront énoncées par mon client, un expert du domaine ou un product owner. La première étape dans l'implémentation passe donc bien évidemment par la compréhension. Vient ensuite le temps de l'expression. Une fois les règles métier acquises, il faudra les ré-exprimer. Que ce soit dans de la documentation ou directement dans du code applicatif, ces règles doivent être clairement retransmises. Aussi bien au moment de l'implémentation initiale que pour la maintenance future du code par d'autres développeurs, l'expression des règles métier doit être limpide. Bien entendu, quelque soit la manière utilisée pour représenter ces règles au sein de l'application nous aurons à coeur d'éviter leur duplication. Comme n'importe quel bout de code, nos règles devront respecter toutes les bonnes pratiques du développement logiciel. Une fois chaque "règle unitaire" écrite, il faudra être capable de les composer pour en créer de plus complexes. Par composition on entend simplement des conjonctions de règles (ET logique), disjonctions (OU logique) et négations.

Specifications

Nous parlions tout à l'heure de design patterns que nous pouvions emprunter à d'autres langages ou que nous faisions émerger. Et bien il existe déjà un pattern pour la problématique de l'expression des règles métier au sein d'une application : le pattern « Specification ». C'est ce pattern et son utilisation qui va nous intéresser.

The specification pattern

“The central idea of Specification is to separate the statement of how to match a candidate, from the candidate object that it is matched against.” Martin Fowler — http://martinfowler.com/apsupp/spec.pdf L'idée principale de ce pattern et de séparer la logique métier – les spécifications – des objets sur lesquels appliquer la logique – les « candidats ». Nous aurons donc deux classes distinctes : l'une contenant les données de notre application et l'autre contenant une règle qui sera utilisable sur ces données.

A specification = a business rule

Specifications are composable

Une spécification permet donc d'exprimer une et une seule règle métier. Chaque règle étant encapsulée dans une classe qui la représente. Pour exprimer des règles plus complexes, les spécifications sont composables (ET, OU et NON).

Webreader

« A book supports the web reader if it's an ePub not protected by Adobe DRM »

Pour imager un peu plus mes propos, voyons concrètement comment implémenter une spécification. Je travaille pour TEA - The Ebook Alternative, une entreprise qui édite une plateforme de vente et distribution de ebooks. Parmi les fonctionnalités de la plateforme on retrouve un webreader qui permet de lire certains ebooks directement dans le navigateur. Nous allons tenter d'implémenter la règle qui indique si un livre donné peut-être ou non lu par ce webreader. À savoir : « un livre peut être lu dans le webreader si c'est un ePub non protégé par Adobe DRM ».

Sample specification

class SupportsWebReader implements Specification
{
    const FORMATS_EPUB = ['epub', 'epub 3', 'epub fixed layout'];

    public function isSatisfiedBy($book)
    {
        return in_array($book->getFormat(), self::FORMATS_EPUB)
            && $book->getProtection() !== 'adobe drm';
    }
}

« A book supports the web reader if it's an ePub not protected by Adobe DRM »

Le pattern Specification nous dit que notre règle métier sera représentée par une classe. Chacune des spécifications que nous écrirons exposera une méthode "isSatisfiedBy" qui permettra de déterminer si un objet donné - ici un livre - satisfait la spécification. L'implémentation de cette méthode relève directement de la traduction de notre règle métier en code. Seulement, rien ne nous permet de composer cette spécification avec d'autres…

Sample specification

class SupportsWebReader implements Specification
{
    const FORMATS_EPUB = ['epub', 'epub 3', 'epub fixed layout'];

    public function isSatisfiedBy($book)
    {
        return in_array($book->getFormat(), self::FORMATS_EPUB)
            && $book->getProtection() !== 'adobe drm';
    }

    public function andX(Specification $spec)
    {
        return new AndSpecification($this, $spec);
    }
    public function orSatisfies(Specification $spec) { /* … */ }
    public function not() { /* … */ }
}

« A book supports the web reader if it's an ePub not protected by Adobe DRM »

Pour ceci on a besoin de trois nouvelles méthodes qui seront les mêmes pour chacune des spécifications que nous écrirons.

Usage

$spec = (new SupportsWebReader())
    ->andX(new AvailableInCountry('FR'))
    ->andX((new PublisherBlacklisted())->not());

$isViewableOnline = $spec->isSatisfiedBy($book); // bool(true)
Mais d'un autre côté l'utilisation et la composition est agréable à écrire et à relire. Une spécification seule n'a que peu d'intérêt : la composition de plusieurs spécifications permet d'exprimer des règles métier plus complexes. On remarque qu'une spécification peut très bien être paramétrée. N.B : la spécification ainsi obtenue représente une "vraie" règle utilisable dans la plateforme. On peut imaginer qu'elle permet de tester si un livre peut être lu en ligne en france.

Pros …

  • SOLID ;
  • unit-testable.
Au point où on en est, on essaie de prendre un peu de recul et d'analyser les avantages et inconvénients des spécifications quant à l'expression de nos règles métier et leur utilisation dans l'application. À priori, on respecte les principes SOLID et bonnes pratiques de développement. On peut même isoler une règle métier fondamentale et l'implémenter de manière testable.

… & cons

  • could be clearer ;
  • only usable on a Book instance.
Mais l'expression de la règle métier pourrait être plus claire et cette spécification n'est utilisable que sur un livre dont on a l'instance ! Comment pouvons-nous récupérer la liste des livres de notre catalogue qui sont lisibles dans le webreader?

RulerZ

RulerZ, une bibliothèque que j'ai créé, se propose de résoudre ces deux problèmes que ne résoud pas le pattern Specification originel.

Features

  • data-agnostic DSL to express business rules ;
  • works at the instance level ;
  • works at the data-source level.
L'idée de RulerZ est simple : on garde nos spécifications mais on les exprime à l'aide d'un DSL (proche du SQL) et surtout on les utilise **aussi** pour récupérer les données satisfaisant ces spécifications. La même spécification peut donc à la fois servir de manière "classique" pour tester un objet donné mais aussi pour récupérer les objets la satisfaisant à partir d'une base de données (via Doctrine, POMM, Eloquent, …), d'Elasticsearch, Solr, … On évite ainsi la duplication de nos règles métier d'une part dans le code et d'autre part dans les requêtes SQL.

Same rule

format IN :formats_epub AND protection != "adobe drm"

« A book supports the web reader if it's an ePub not protected by Adobe DRM »

Le DSL est simple, extensible, volontairement très proche du SQL (mêmes objectifs !) et permet d'exprimer aisément nos règles métier. On retrouve ici la règle écrite précédemment.

Same usage

$rule = 'format IN :formats_epub AND protection != "adobe drm"';

// use the textual rule
$isViewableOnline = $rulerz->satisfies($book, $rule, [
    'formats_epub' => ['epub', 'epub 3', 'epub fixed layout'],
]); // bool(true)
L'utilisation est aussi simple qu'habituellement. On a d'un côté notre règle textuelle, de l'autre l'objet à tester et on passe les deux à RulerZ. On obtient toujours en sortie un booléen.

Same specification

class SupportsWebReader extends AbstractSpecification
{
    public function getRule()
    {
        return 'format IN :formats_epub AND protection != "adobe drm"';
    }

    public function getParameters()
    {
        return [
            'formats_epub' => ['epub', 'epub 3', 'epub fixed layout'],
        ];
    }
}

« A book supports the web reader if it's an ePub not protected by Adobe DRM »

Bien entendu, travailler avec des objets représentant nos spécifications permet de les tester et composer plus facilement qu'avec de simples chaines de caractères. Une specification ne fait qu'encapsuler une règle textuelle en les rendant testables et en permettant de les réutiliser un peu partout dans la base de code.

Same usage

// build a specification object
$spec = (new SupportsWebReader())
    ->andX(new AvailableInCountry('FR'))
    ->andX((new PublisherBlacklisted())->not());

$isViewableOnline = $rulerz->satisfiesSpec($book, $spec); // bool(true)
Que ce soit avec une règle textuelle ou un object de spécification, vérifier qu'un objet lui est conforme est toujours aussi facile.

Usage on a datasource

// our app uses Doctrine to query the database
$queryBuilder = $entityManager
    ->createQueryBuilder()
    ->select('book')
    ->from('Entity\Book', 'book');

// and we want to find the viewable online books
$viewableOnlineBooks = $rulerz->filterSpec($queryBuilder, $spec);

var_dump($viewableOnlineBooks); // array<Entity\Book>
Même règle ou spécification, mais cette fois on récupère des données au lieu de vérifier la validité d'un objet qu'on a déjà. Il est important de noter qu'à la place d'un QueryBuilder Doctrine, on aurait pu utiliser Pomm, ou un client Elasticsearch pour aller chercher les données ailleurs. Une règle métier exprimée une seule fois dans le code permet donc de valider un objet ou de retrouver tous les objets la validant. Plus de duplication ! En bonus, l'utilisations est aussi simple que pour un objet unique : la règle et la source de données sont tout ce dont RulerZ à besoin.

Under the hood

À ce moment là de ma présentation, l'audience commence à se poser des questions : on gagne en lisibilité, on déduplique du code… mais que perd-on ? Les performances peut-être ?

Architecture

RuleParserCompilerPHP codeSQL queryES queryIRTargets
Pour montrer que les performances sont toujours très bonnes nous allons rapidement voir comment RulerZ fonctionne. Car en fait, RulerZ n'est rien d'autre qu'un compilateur qui va traduire vos règles métier vers du code PHP natif, du SQL, des requêtes Elasticsearch, … Mis à part le coût de compilation à la première utilisation de la règle, les performances sont donc quasiment natives ! Pour ceux qui seraient intéressés, la partie du compilateur qui gère l'analyse du DSL utilise https://github.com/hoaproject/Compiler/ pour fonctionner.

A few use cases

Nous avons vu que RulerZ n'est qu'une implémentation du pattern Specification, même si elle l'augmente considérablement en rajoutant une fonctionnalité de récupération de données. Mais est-ce que c'est tout ce que RulerZ peut faire ? Spoiler alert : nope !

Repositories – Before

class DoctrineBookRepository implements BookRepository
{
    public function findByEan($ean) { }
    public function findByTitle($title) { }
    public function findPublished() { }
    public function findViewableOnline() { }
    public function findNotViewableOnline() { }

    public function findPublishedAndViewableOnline() { }

    // …
}
Doctrine les met en avant mais c'est une pratique répandue : les Repository permettent d'isoler l'accès au données du reste de l'application. Le soucis vient de l'explosion du nombre de méthodes à implémenter pour permettre d'accéder aux données ... pas très SOLID !

Repositories – After

class DoctrineBookRepository implements BookRepository
{
    public function matching(Specification $spec)
    {
        $qb = $this->createQueryBuilder('book');

        return $this->rulerz->satisfiesSpec($qb, $spec);
    }
}
Ce problème est résolu par l'utilisation conjointe des spécifications et de RulerZ, dans une méthode matching. Une méthode sachant retourner les données correspondant à une spécification, des spécifications décrivant ces données, le tour est joué ! N.B : il faut bien entendu rester pragmatiques. Rien n'empêche d'avoir cette méthode "matching" en conjonction d'autres méthodes plus "techniques" dont la valeur ajoutée est faible en terme de métier (récupérer un objet par son identifiant par exemple). L'utilisation de spécification doit se faire en priorité lorsque la valeur métier le justifie.

Search forms

One field → One specification object

Face à un formulaire aussi massif que celui-ci et destiné uniquement à filtrer des données on peut considérer chaque champ comme une "spécification". En tirant parti (par exemple) du composant Form de Symfony on peut aisément convertir chaque valeur saisie par l'utilisateur en son équivalent en spécification et se reposer sur RulerZ pour tout ce qui concerne le filtrage des données.

Wallabag

Tagging rules

Other use cases

e-commerce coupons / …

L'exemple classique des bons de réduction : un administrateur peut saisir lui-même via une interface les conditions d'utilisation d'un bon de réduction. Ces règles d'attributions permettront à la fois de vérifier qu'un bon de réduction peut être utilisé par un client, mais aussi d'être proactif et d'envoyer un mail aux clients concernés pour les prévenir et les pousser à l'achat.

Going further

Thanks!

http://bit.ly/stage-tea-2016

Kévin Gomez / @KPhoen

1
Be specific Forum PHP 2015 Kévin Gomez / @KPhoen