Monolithische codebasis converteren naar….

Laat ik beginnen met een zicht van 1000 ft.

Dit is een typisch afrekenproces voor e-commerce waarbij meerdere soorten klanten via meerdere kanalen bestellingen kunnen plaatsen. Links de meeste sites van pic-1 zijn kanalen: mobiel / site / klantenservice / verkooppunt / 3e partij en nog veel meer aangepaste kanalen.

Elke klant heeft een andere set validatie- en bedrijfsregels om een ​​bestelling te plaatsen. Ze hebben ook een ander niveau van orkestratie om regels / services te bellen, bijvoorbeeld Customer Care verzamelt alle gegevens op hun systeem en plaatst een bestelling door direct placeOrder te bellen.

Online / mobiel roept de methode Create / Update en Place Order op. Customer Care voert bedrijfsregels uit in een andere volgorde dan de bestelling die is geplaatst vanaf de site / mobiel. POS heeft ook een andere set regels die een validatieketen willen oproepen of regels op een andere volgorde. Hieronder volgen bijvoorbeeld verschillende regels / kenmerken van elke klant / kanalen.

Niet alle kanalen kunnen alle typen gebruiken als betalingen zoals -Online wordt gebruikt – CC, Paypal en GiftCard. Mobiel kan bovendien GooglePay / ApplePay gebruiken. De klantenservice kan alleen creditcard en cadeaukaart gebruiken.

Nog maar een paar voorbeelden van bedrijfsregels

Klantenservice

Online

Mobiele bestelling

Gezien dit soort orders en regels zijn er veel minder, maar in werkelijkheid zijn er veel bedrijfsregels.

Probleem wordt getoond in het onderstaande diagram-

Er is een enkele gevellaag die 1000 regels van enkele methoden aanroept die intern verdere ketens van methoden aanroept met ton if / else verspreid over de hele code. Dit heeft voor veel complexiteit gezorgd en vanwege verspreide code is er ook veel dubbele code toegevoegd. Als u een code op de ene plaats wijzigt, heeft dit invloed op een andere stroom en is het erg moeilijk om unit-tests uit te voeren. Het voegt ook te veel verwarring toe omdat overal voorwaarden zijn gebaseerd op klant / kanalen / type bestelling / verzendmethoden enz.

Om deze code te refracteren hebben we het volgende ontwerp bedacht met i , waarbij elke klant zijn eigen gevellaag zal hebben die wordt aangeroepen door de voorgevel (Routing Gateway) gebaseerd kanaal / client. Elke klantspecifieke gevel kan zijn eigen specifieke regels orkestreren en definiëren en deze in hun eigen gedefinieerde volgorde uitvoeren. Er zal een aparte laag zijn met client-agnostische validatie en regels die door elke client kunnen worden aangeroepen.

Opmerking: behalve 3rdPaties, zullen alle andere teams bijdragen aan het schrijven van codes voor dit afrekenproces en een kernteam zal alle algemene regels / validatie / persistentie / stroomafwaartse connectiviteit enz. definiëren.