Einführung

In den vorherigen Artikeln haben wir beschrieben: Umfang , methodische Grundlagen , ein Beispiel für Architektur und Struktur . In diesem Artikel möchte ich erläutern, wie die Prozesse beschrieben werden, welche Prinzipien zum Sammeln von Anforderungen gelten, wie sich Geschäftsanforderungen von funktionalen unterscheiden und wie von Anforderungen zu Code gewechselt wird. Sprechen Sie über die Prinzipien der Verwendung des Anwendungsfalls und wie sie uns helfen können. Sehen Sie sich Beispiele für Implementierungsoptionen für Interactor- und Service Layer-Entwurfsmuster an.

Die im Artikel angegebenen Beispiele werden mit unserer LunaPark- Lösung gegeben. Sie hilft Ihnen bei den ersten Schritten in den beschriebenen Ansätzen.

Trennen Sie funktionale Anforderungen von Geschäftsanforderungen.

Immer wieder kommt es vor, dass viele Geschäftsideen nicht wirklich zum endgültigen, beabsichtigten Produkt werden. Dies ist häufig darauf zurückzuführen, dass der Unterschied zwischen Geschäftsanforderungen und funktionalen Anforderungen nicht verstanden werden kann, was letztendlich zu einer unzureichenden Erfassung von Anforderungen, unnötiger Dokumentation, Projektverzögerungen und größeren Projektfehlern führt.

Oder manchmal sind wir mit Situationen konfrontiert, in denen die endgültige Lösung zwar den Bedürfnissen der Kunden entspricht, die Geschäftsziele jedoch irgendwie nicht erreicht werden.

Daher ist es unbedingt erforderlich, die Geschäftsanforderungen von den funktionalen Anforderungen zu trennen, bis Sie mit der Definition beginnen. Nehmen wir ein Beispiel.

Angenommen, wir schreiben einen Antrag für eine Pizza-Lieferfirma und haben beschlossen, ein Kurier-Tracking-System zu erstellen. Die Geschäftsanforderungen lauten wie folgt:

"Einführung eines webbasierten Systems und eines mobilen, auf Mitarbeitern basierenden Mitarbeiterverfolgungssystems, das Kuriere auf ihren Routen erfasst und die Effizienz verbessert, indem die Aktivitäten der Kuriere, ihre Abwesenheit von der Arbeit und die Arbeitsproduktivität überwacht werden."

Hier können wir eine Reihe von charakteristischen Merkmalen unterscheiden, die darauf hinweisen, dass dies Anforderungen aus dem Geschäft sind:

• Geschäftsanforderungen werden immer aus Sicht des Kunden geschrieben;
• Dies sind breite Anforderungen auf hoher Ebene, die jedoch immer noch teilorientiert sind.
• Sie sind keine Unternehmensziele, sondern helfen dem Unternehmen, Ziele zu erreichen.
• Beantworten Sie die Fragen „ Warum “ und „ Was “. Was möchte das Unternehmen erhalten? Und warum braucht sie es?

Funktionale Anforderungen sind Aktionen , die das System ausführen muss, um Geschäftsanforderungen zu implementieren. Somit hängen die funktionalen Anforderungen mit der entwickelten Lösung oder Software zusammen. Wir formulieren die funktionalen Anforderungen für das obige Beispiel:

• Das System sollte den Längen- und Breitengrad des Mitarbeiters über GPS / GLONASS anzeigen.
• Das System sollte die Positionen der Mitarbeiter auf der Karte anzeigen.
• Das System sollte es Managern ermöglichen, Benachrichtigungen an ihre Außendienstmitarbeiter zu senden.

Wir heben die folgenden Merkmale hervor:

• funktionale Anforderungen werden immer aus Sicht des Systems geschrieben;
• sie sind spezifischer und detaillierter;
• Dank der Erfüllung der funktionalen Anforderungen wird eine effektive Lösung entwickelt, die den Anforderungen des Unternehmens und den Zielen des Kunden entspricht.
• Beantworten Sie die Frage " wie ". Wie das System Geschäftsanforderungen löst.

Es sollten einige Worte zu nicht funktionalen Anforderungen (auch als „Qualitätsanforderungen“ bezeichnet) gesagt werden, die das Design oder die Implementierung einschränken (z. B. Anforderungen an Leistung, Sicherheit, Verfügbarkeit, Zuverlässigkeit). Solche Anforderungen beantworten die Frage, was das System sein soll.

Entwicklung ist die Übersetzung von Geschäftsanforderungen in funktionale. Angewandte Programmierung ist die Implementierung funktionaler Anforderungen und des Systems - nicht funktionsfähig.

Anwendungsfälle

Die Implementierung funktionaler Anforderungen ist in kommerziellen Systemen häufig die komplexeste. In einer reinen Architektur werden funktionale Anforderungen über die Use-Case- Ebene implementiert.

Aber für den Anfang möchte ich mich an die Quelle wenden. Ivar Jacobson - der Autor der Definition von Use Case , einer der Autoren von UML, und der RUP-Methodik in seinem Artikel Use-Case 2.0 Der Hub of Software Development identifiziert 6 Prinzipien für die Verwendung von Use Cases :

1. mach sie einfach durch Geschichtenerzählen;
2. einen strategischen Plan haben, das ganze Bild kennen;
3. Fokus auf Bedeutung;
4. Richten Sie das System in Schichten aus.
5. liefern Sie das System Schritt für Schritt;
6. die Bedürfnisse des Teams erfüllen.

Wir betrachten kurz jedes dieser Prinzipien, sie sind für uns zum weiteren Verständnis nützlich. Unten finden Sie meine kostenlose Übersetzung mit Abkürzungen und Beilagen. Ich empfehle Ihnen dringend, sich mit dem Original vertraut zu machen.

Einfachheit durch Geschichtenerzählen

Erzählung ist Teil unserer Kultur; Dies ist der einfachste und effektivste Weg, um Wissen und Informationen von einer Person zur anderen zu übertragen. Dies ist der beste Weg, um zu kommunizieren, was das System tun soll, und um dem Team zu helfen, sich auf gemeinsame Ziele zu konzentrieren.

Anwendungsfälle spiegeln die Systemziele wider. Um den Anwendungsfall zu verstehen, erzählen wir eine bestimmte Geschichte. Die Geschichte erzählt, wie man ein Ziel erreicht und Probleme löst, die auf dem Weg entstehen. Anwendungsfälle wie ein Storybook bieten eine Möglichkeit, die verschiedenen, aber verwandten Geschichten auf einfache und umfassende Weise zu identifizieren und zu behandeln. Dies erleichtert das Sammeln, Verteilen und Verstehen von Systemanforderungen.

Dieses Prinzip korreliert mit der Ubiques-Sprache aus dem DDD-Ansatz.

Das ganze Bild verstehen

Unabhängig davon, welches System Sie entwickeln, ob groß, klein, Software, Hardware oder Unternehmen, ist es sehr wichtig, das Gesamtbild zu verstehen. Ohne das System als Ganzes zu verstehen, können Sie nicht die richtigen Entscheidungen darüber treffen, was in das System aufgenommen werden soll, was ausgeschlossen werden soll, wie viel es kosten wird und welche Vorteile es bringen wird.

Ivar Jacobson schlägt vor, das Anwendungsfalldiagramm zu verwenden , das zum Sammeln von Anforderungen sehr praktisch ist. Wenn die Anforderungen kompiliert und klar sind, ist die Kontextkarte von Eric Evans die beste Option. Oft wird der Scrum-Ansatz so interpretiert, dass die Menschen keine Zeit mit einem strategischen Plan verbringen, da sie mehr als zwei Wochen später ein Relikt der Vergangenheit planen. Jeff Sutherlands Propaganda fiel auf den Wasserfluss, und Leute, die zweiwöchige Schulungen für Scrum Masters absolvierten, die Projekte verwalten durften, machten ihre Arbeit. Der gesunde Menschenverstand erkennt jedoch die Bedeutung der strategischen Planung an. Es ist nicht erforderlich, einen detaillierten Strategieplan zu erstellen, dies sollte jedoch der Fall sein.

Wert im Fokus

Wenn Sie versuchen zu verstehen, wie das System verwendet wird, ist es immer wichtig, sich auf den Wert zu konzentrieren, den es seinen Benutzern und anderen interessierten Parteien bietet. Wert wird nur gebildet, wenn das System verwendet wird. Daher ist es viel besser, sich auf die Anwendung des Systems zu konzentrieren, als auf lange Listen von Funktionen, die es bieten kann.

Anwendungsfälle bieten diesen Fokus und helfen Ihnen, sich darauf zu konzentrieren, wie das System von einem bestimmten Benutzer verwendet wird, um sein Ziel zu erreichen. Anwendungsfälle decken viele Möglichkeiten zur Verwendung des Systems ab: diejenigen, die ihre Ziele erfolgreich erreichen, und diejenigen, die auftretende Schwierigkeiten lösen.

Darüber hinaus gibt der Autor ein wunderbares Schema, dem die größte Aufmerksamkeit geschenkt werden sollte:

Das Diagramm zeigt einen Anwendungsfall „Bargeldbezug an einem Geldautomaten“. Der einfachste Weg, um das Ziel zu erreichen, ist in der Grundrichtung (Grundablauf) beschrieben. Andere Fälle werden als alternativer Fluss beschrieben. Diese Anweisungen helfen beim Geschichtenerzählen, beim Strukturieren des Systems und beim Schreiben von Tests.

Schichtung

Die meisten Systeme erfordern viel Arbeit, bevor sie einsatzbereit sind. Sie haben viele Anforderungen, von denen die meisten von anderen Anforderungen abhängen. Sie müssen implementiert werden, bevor die Anforderungen erfüllt und bewertet werden.

Es ist ein großer Fehler, jeweils ein solches System zu erstellen. Das System sollte aus Teilen aufgebaut sein, von denen jedes für die Benutzer einen eindeutigen Wert hat.

Diese Ideen finden Resonanz bei agilen Ansätzen und bei Domain- Ideen.

Schrittweise Produkteinführung

Die meisten Softwaresysteme haben sich über viele Generationen hinweg weiterentwickelt. Sie werden nicht gleichzeitig produziert; Sie bestehen aus einer Reihe von Versionen, von denen jede auf einer früheren Version basiert. Sogar die Veröffentlichungen selbst gehen oft nicht sofort aus, sondern entwickeln sich durch eine Reihe von Zwischenversionen. Jeder Schritt bietet eine klare, verwendbare Version des Systems. Auf diese Weise sollten alle Systeme erstellt werden.

Erfüllen Sie die Bedürfnisse des Teams

Leider gibt es keine universelle Lösung für Softwareentwicklungsprobleme. Unterschiedliche Teams und unterschiedliche Situationen erfordern unterschiedliche Stile und unterschiedliche Detaillierungsgrade. Unabhängig davon, für welche Methoden und Techniken Sie sich entscheiden, müssen Sie sicherstellen, dass sie anpassungsfähig genug sind, um den aktuellen Anforderungen des Teams gerecht zu werden.

Eric Evans fordert Sie in seinem Buch auf, nicht viel Zeit damit zu verbringen, alle Prozesse über UML zu beschreiben. Es reicht aus, visuelle Schemata zu verwenden. Unterschiedliche Teams, unterschiedliche Projekte erfordern unterschiedliche Detaillierungsgrade, da der UML-Autor selbst darüber spricht.

Implementierung

In der reinen Architektur definiert Robert Martin die folgenden Anwendungsfälle :

Diese Anwendungsfälle koordinieren den Datenfluss zu und von den Entitäten und weisen diese Entitäten an, ihre kritischen Geschäftsregeln zu verwenden, um die Ziele des Anwendungsfalls zu erreichen.

Versuchen wir, diese Ideen in Code zu übersetzen. Erinnern wir uns an das Schema aus dem dritten Prinzip der Verwendung der Anwendungsfälle und nehmen es als Grundlage. Stellen Sie sich einen wirklich komplexen Geschäftsprozess vor: „Kochen eines Kohlkuchens“.

Versuchen wir es zu zerlegen:

• Produktverfügbarkeit prüfen;
• nimm sie aus dem Lager;
• den Teig kneten;
• lass den Teig aufgehen;
• bereite die Füllung vor;
• einen Kuchen machen;
• backe einen Kuchen.

Wir implementieren diese gesamte Sequenz über den Interactor , und jeder Schritt wird über eine Funktion oder ein Funktionsobjekt auf der Serviceschicht implementiert.

Reihenfolge der Aktionen (Interaktor)

Ich empfehle dringend, die Entwicklung eines komplexen Geschäftsprozesses mit der Reihenfolge der Aktionen zu beginnen . Genauer gesagt, müssen Sie die Domain Domain bestimmen, zu der der Geschäftsprozess gehört. Klären Sie alle geschäftlichen Anforderungen. Identifizieren Sie alle am Prozess beteiligten Entitäten . Dokumentieren Sie die Anforderungen und Definitionen jeder Entität in der Wissensdatenbank.

Malen Sie alles schrittweise auf Papier. Manchmal benötigen Sie ein Sequenzdiagramm. Sein Autor ist derselbe, der den Anwendungsfall erfunden hat - Ivar Jacobson. Das Diagramm wurde von ihm erfunden, als er für Erickson ein auf der Relaisschaltung basierendes Telefonnetz-Wartungssystem entwickelte. Ich mag dieses Diagramm sehr und der Begriff Sequenz ist meiner Meinung nach aussagekräftiger als der Begriff Interactor . In Anbetracht der größeren Verbreitung des letzteren werden wir den bekannten Begriff Interactor verwenden .

Ein kleiner Hinweis, wenn Sie einen Geschäftsprozess beschreiben, ist eine gute Hilfe für Sie. Die Hauptregel der Dokumentenverwaltung kann lauten: „Als Ergebnis einer Geschäftstätigkeit sollte ein Dokument erstellt werden.“ Zum Beispiel entwickeln wir ein Rabattsystem. Mit einem Rabatt schließen wir aus geschäftlicher Sicht eine Vereinbarung zwischen dem Unternehmen und dem Kunden. Alle Bedingungen müssen in diesem Vertrag festgelegt werden. Das heißt, in der DiscountSystem-Domäne haben Sie Entites :: Contract. Binden Sie den Rabatt nicht an den Kunden, sondern erstellen Sie einen Unternehmensvertrag, in dem die Regeln für seine Bereitstellung beschrieben werden.

Kehren wir zur Beschreibung unseres Geschäftsprozesses zurück, nachdem er für alle an seiner Entwicklung beteiligten Personen transparent geworden ist und Ihr gesamtes Wissen feststeht. Ich empfehle Ihnen, Code mit der Reihenfolge der Aktionen zu schreiben.

Die Sequenzdesign- Vorlage ist verantwortlich für:

• Abfolge von Aktionen ;
• Koordination der übertragenen Daten zwischen Aktionen ;
• Verarbeitungsfehler, die von Aktionen während ihrer Ausführung begangen wurden;
• Rückgabe des Ergebnisses der zugesagten Aktionen ;
• WICHTIG : Die wichtigste Verantwortung für dieses Entwurfsmuster ist die Implementierung der Geschäftslogik.

Ich möchte näher auf die letzte Verantwortung eingehen, wenn wir einen komplexen Prozess haben - wir müssen ihn so beschreiben, dass klar ist, was passiert, ohne auf technische Details einzugehen. Sie sollten es so aussagekräftig beschreiben, wie es Ihre Programmierkenntnisse zulassen . Vertrauen Sie diese Klasse dem erfahrensten Mitglied Ihres Teams an.

Kehren wir zum Kuchen zurück: Versuchen wir, den Prozess seiner Vorbereitung durch Interactor zu beschreiben.

Implementierung

Ich gebe eine Beispielimplementierung mit unserer LunaPark- Lösung, die wir in einem früheren Artikel vorgestellt haben.

module Kitchen module Sequences class CookingPieWithabbage < LunaPark::Interactors::Sequence TEMPERATURE = Values::Temperature.new(180, unit: :cel) def call! Services::CheckProductsAvailability.call list: ingredients dough = Services::BeatDough.call from: Repository::Products.get(beat_ingredients) filler = Services::MakeabbageFiller.call from: Repository::Products.get(filler_ingredients) pie = Services::MakePie.call dough, with: filler bake = Services::BakePie.new pie, temp: TEMPERATURE sleep 5.min until bake.call pie end private attr_accessor :beat_ingredients, :filler_ingredients attr_accessor :pie def ingredients_list beat_ingredients_list + filler_ingredients_list end end end end 

Wie wir sehen können, ist der call! beschreibt die gesamte Geschäftslogik des Kuchenbackprozesses. Und es ist bequem zu verwenden, um die Logik der Anwendung zu verstehen.

Außerdem können wir den Prozess des Backens von Fischpastete leicht beschreiben, indem MakeabbageFiller MakeFishFiller durch MakeabbageFiller MakeFishFiller . Daher ändern wir den Geschäftsprozess sehr schnell, ohne wesentliche Codeänderungen. Außerdem können wir beide Sequenzen gleichzeitig belassen und Geschäftsfälle skalieren.

Arrangements

• Methode call! ist eine erforderliche Methode und beschreibt die Reihenfolge der Aktionen .
• Jeder Initialisierungsparameter kann durch einen Setter oder attr_acessor :

 class Foo < LunaPark::Interactors::Sequence # ... private attr_accessor :bar end Foo.call(bar: 42) 

• Der Rest der Methoden sollte privat sein.

Anwendungsbeispiel

 beat_ingredients = [ Entity::Product.new :flour, 500, :gr, Entity::Product.new :oil, 50, :gr, Entity::Product.new :salt, 1, :spoon, Entity::Product.new :milk, 150, :ml, Entity::Product.new :egg, 1, :unit, Entity::Product.new :yeast, 1, :spoon ] filler_ingredients = [ Entity::Product.new :cabbage, 500, :gr, Entity::Product.new :salt, 1, :spoon, Entity::Product.new :pepper, 1, :spoon ] cooking = CookingPieWithabbage.call( beat_ingredients: beat_ingredients, filler_ingredients: filler_ingredients ) #   : cooking.success? # => true cooking.fail # => false cooking.fail_message # => '' cooking.data # => Entity::Pie #   : cooking.success? # => false cooking.fail # => true cooking.fail_message # => 'The pie burned out' cooking.data # => nil 

Der Prozess wird durch das Objekt dargestellt und wir haben alle notwendigen Methoden, um es aufzurufen - war der Aufruf erfolgreich, ist während des Aufrufs ein Fehler aufgetreten, und wenn ja, welche?

Fehlerbehandlung

Wenn wir uns jetzt an das dritte Prinzip der Use-Case-Anwendung erinnern, achten wir darauf, dass wir neben der Hauptzeile auch alternative Anweisungen hatten. Dies sind Fehler, die wir behandeln müssen. Stellen Sie sich ein Beispiel vor: Wir möchten sicher nicht, dass Ereignisse in diese Richtung verlaufen, aber wir können nichts dagegen tun. Die harte Realität ist, dass die Kuchen regelmäßig verbrannt werden.

Interactor fängt alle Fehler ab, die von der LunaPark::Errors::Processing Klasse geerbt wurden.

Wie verfolgen wir den Kuchen? Definieren Sie dazu den Fehler Burned in der BakePie Aktion .

 module Kitchen module Errors class Burned < LunaPark::Errors::Processing; end end end 

Und stellen Sie beim Backen sicher, dass unser Kuchen nicht ausgebrannt ist:

 module Kitchen module Services class BakePie < LunaPark::Callable def call # ... rescue Errors::Burned, 'The pie burned out' if pie.burned? # ... end end end end 

In diesem Fall funktioniert die Fehlerfalle, und wir können sie in .
Fehler, die nicht von der Processing geerbt wurden, werden als Systemfehler wahrgenommen und auf Serverebene abgefangen. Sofern nicht anders angegeben, erhält der Benutzer einen 500 ServerError.

Übungsgebrauch

1. Versuchen Sie, alle Aufrufe in der Aufrufmethode zu beschreiben!

Sie sollten nicht jede Aktion in einer separaten Methode implementieren. Dadurch wird der Code aufgeblähter. Sie müssen die gesamte Klasse mehrmals betrachten, um zu verstehen, wie es funktioniert. Verwöhne das Rezept zum Backen eines Kuchens:

 module Service class CookingPieWithabbage < LunaPark::Interactors::Sequence def call! check_products_availability make_cabbage_filler make_pie bake end private def check_products_availability Services::CheckProductsAvailability.call list: ingredients end # ... end end 

Verwenden Sie den Aktionsaufruf direkt im Klassenzimmer. Aus der Sicht von Ruby mag dieser Ansatz ungewöhnlich erscheinen, sodass er besser lesbar erscheint:

 class DrivingStart < LunaPark::Interactors::Sequence def call! Service::CheckEngine.call Service::StartUpTheIgnition.call car, with: key Service::ChangeGear.call car.gear_box, to: :drive Service::StepOnTheGas.call car.pedals[:right] end end 

2. Verwenden Sie nach Möglichkeit die Aufrufklassenmethode

 # good - ,   ,  . #    . Sequence::RingingToPerson.call(params) # good -   ,      e, #    ,     , #    . ring = Sequence::RingingToPerson.new(person) unless ring.success? ring.call sleep 5.min end 

3. Erstellen Sie keine funktionalen Objekte, um den Code einzugeben. Sehen Sie sich die Situation an

 # bad -        ,  #     . module Services class BuildUser < LunaPark::Callable def initialize(first_name:, last_name:, phone:) @first_name = first_name @last_name = last_name @phone = phone end def call Entity::User.new( first_name: first_name, last_name: last_name, phone: phone ) end private attr_reader :first_name, :last_name, :phone end end module Sequences class RegisteringUser < LunaPark::Interactors::Sequence attr_accessor :first_name, :last_name, :phone def call! user = Service::BuildUser.call(first_name: first_name, last_name: last_name, phone: phone) end end end # good -     ,  . #        , #       . module Sequences class RegisteringUser < LunaPark::Interactors::Sequence attr_accessor :first_name, :last_name, :phone def call! user #... end private def user @user = Entity::User.new( first_name: first_name, last_name: last_name, phone: phone ) end end end 

Serviceschicht

Der Interactor beschreibt, wie gesagt, die Geschäftslogik auf höchstem Niveau. Die Serviceschicht (Serviceschicht) zeigt bereits die Details der Implementierung funktionaler Anforderungen. Wenn wir über die Herstellung eines Kuchens sprechen, sagen wir auf der Ebene des Interactor einfach „Knete den Teig“, ohne auf Einzelheiten darüber einzugehen, wie man ihn knetet. Der Knetvorgang wird auf Serviceebene beschrieben . Kehren wir zur ursprünglichen Quelle zurück, dem großen blauen Buch :

In der angewendeten Domäne gibt es Operationen, die keinen natürlichen Ort in einem Objekt vom Typ Entität oder Wertobjekt finden können. Sie sind von Natur aus keine Objekte, sondern Aktivitäten. Da die Grundlage unseres Modellierungsparadigmas jedoch der Objektansatz ist, werden wir versuchen, sie in Objekte umzuwandeln.

An dieser Stelle ist es leicht, einen häufigen Fehler zu machen: den Versuch aufzugeben, die Operation in einem geeigneten Objekt dafür zu platzieren, und so zur prozeduralen Programmierung zu gelangen. Wenn Sie jedoch eine Operation mit Gewalt in ein Objekt mit einer ihm fremden Definition einfügen, verliert das Objekt selbst seine Reinheit, was das Verständnis und die Umgestaltung erschwert. Wenn Sie viele komplexe Vorgänge in einem einfachen Objekt implementieren, kann dies zu einem unverständlichen Ergebnis führen. Was Sie tun, ist nicht klar, was. Solche Operationen betreffen oft andere Objekte des Themenbereichs, und die Koordination zwischen ihnen wird durchgeführt, um eine gemeinsame Aufgabe auszuführen. Zusätzliche Verantwortung schafft Abhängigkeitsketten zwischen Objekten und mischt Konzepte, die unabhängig voneinander betrachtet werden können.

Verwenden Sie bei der Auswahl eines Standorts für die Implementierung einer Funktion immer den gesunden Menschenverstand. Ihre Aufgabe ist es, das Modell ausdrucksvoller zu machen. Schauen wir uns ein Beispiel an: "Wir müssen Holz hacken":

 module Entities class Wood def chop # ... end end end 

Diese Methode wird ein Fehler sein. Brennholz wird sich nicht selbst hacken, wir brauchen eine Axt:

 module Entities class Axe def chop(sacrifice) # ... end end end 

Wenn wir ein vereinfachtes Geschäftsmodell verwenden, reicht dies aus. Wenn der Prozess jedoch detaillierter modelliert werden muss, benötigen wir eine Person, die dieses Brennholz hackt, und möglicherweise ein Protokoll, das als Ständer für den Prozess verwendet wird.

 module Entities class Human def chop_firewood(wood, axe, chock) # ... end end end 

Wie Sie wahrscheinlich bereits vermutet haben, ist dies keine gute Idee. Nicht alle von uns sind mit dem Schneiden von Holz beschäftigt, dies ist keine direkte Pflicht einer Person. Wir sehen oft, wie überlastet die Modelle in Ruby on Rails sind, die eine ähnliche Logik enthalten: Rabatte erhalten, Waren in den Warenkorb legen, Geld auf den Kontostand abheben. Diese Logik gilt nicht für die Entität, sondern für den Prozess, an dem diese Entität beteiligt ist.

 module Services class ChopFirewood # ... end end 

Nachdem wir herausgefunden haben, welche Logik wir in den Diensten speichern , werden wir versuchen, eine davon zu implementieren. In den meisten Fällen werden Dienste über Methoden oder Funktionsobjekte implementiert.

Funktionsobjekte

Ein Funktionsobjekt erfüllt eine Funktionsanforderung. In seiner primitivsten Form hat ein funktionales Objekt eine einzige öffentliche Methode - den call .

 module Serivices class Sum def initialize(x, y) @x = x @y = y end def call x + y end def self.call(x,y) new(x,y).call end private attr_reader :x, :y end end 

Solche Objekte haben mehrere Vorteile: Sie sind präzise und sehr einfach zu testen. Es gibt einen Nachteil, solche Objekte können sich als große Anzahl herausstellen. Es gibt verschiedene Möglichkeiten, ähnliche Objekte zu gruppieren. In einem Teil unserer Projekte teilen wir sie nach Typ:

• Serviceobjekt (Service) - Ein Objekt, das ein neues Objekt erstellt.
• Befehl (Befehl) - Ändert das aktuelle Objekt.
• Guardian (Guard) - Gibt einen Fehler zurück, wenn ein Fehler aufgetreten ist.

Serviceobjekt

In unserer Implementierung implementiert Service - eine funktionale Anforderung und gibt immer einen Wert zurück.

 module KorovaMilkBar module Services class FindMilk < LunaPark::Callable GLASS_SIZE = Values::Unit.wrap '200g' def initialize(fridge:) @fridge = fridge end def call fridge.shelfs.find { |shelf| shelf.has?(GLASS_SIZE, of: :milk) } end private attr_reader :fridge end end end FindMilk.call(fridge: the_red_one) # => #<Glass: ... > 

Befehl

In unserer Implementierung führt Command - eine Aktion aus und ändert das Objekt, wenn true true zurückgibt. Tatsächlich erstellt das Team kein Objekt, sondern ändert ein vorhandenes.

 module KorovaMilkBar module Commands class FillGlass < LunaPark::Callable def initialize(glass, with:) @glass = glass @content = with end def call glass << content true end private attr_reader :fridge end end end glass = Glass.empty milk = Milk.new(200, :gr) glass.empty? # => true FillGlass.call glass, with: milk # => true glass.empty? # => false 

Wächter (Wache)

Der Watchman führt eine logische Prüfung durch und gibt im Fehlerfall einen Verarbeitungsfehler aus. Diese Art von Objekt wirkt sich in keiner Weise auf die Hauptrichtung aus, sondern wechselt in die alternative Richtung, wenn etwas schief geht.

Beim Servieren von Milch ist darauf zu achten, dass sie frisch ist:

 module KorovaMilkBar module Guards class IsFresh < LunaPark::Callable def initialize(product) @products = products end def call products.each do |product| raise Errors::Rotten, "#{product.title} is not fresh" if product.expiration_date > Date.today end nil end private attr_reader :products end end end 

Möglicherweise ist es zweckmäßig, Funktionsobjekte nach Typ zu trennen. Sie können beispielsweise Ihren eigenen Builder hinzufügen - erstellt ein Objekt basierend auf Parametern.

Arrangements

• Die call ist die einzige obligatorische öffentliche Methode.
• Die initialize ist die einzige optionale öffentliche Methode.
• Der Rest der Methoden sollte privat sein.
• Logische Fehler müssen von der Klasse LunaPark::Errors::Processing geerbt werden.

Fehlerbehandlung

Es gibt zwei Arten von Fehlern, die während der Ausführung einer Aktion auftreten können .

Laufzeitfehler

Solche Fehler können infolge einer Verletzung der Verarbeitungslogik auftreten.

Zum Beispiel:

• beim Erstellen eines Benutzers ist E-Mail reserviert;
• Wenn Sie versuchen, Milch zu trinken, ist es vorbei.
• Ein anderer Microservice lehnte die Aktion ab (aus einem logischen Grund und nicht, weil der Service nicht verfügbar ist).

Höchstwahrscheinlich möchte der Benutzer über diese Fehler informiert werden. Auch das sind wahrscheinlich die Fehler
was wir vorhersehen können.

Solche Fehler sollten von LunaPark::Errors::Processing geerbt werden

Systemfehler

Fehler, die infolge eines Systemabsturzes aufgetreten sind.

Zum Beispiel:

• Die Datenbank funktioniert nicht.
• etwas geteilt durch Null.

Höchstwahrscheinlich können wir diese Fehler nicht vorhersehen und dem Benutzer nichts sagen, außer dass alles sehr schlecht ist, und den Entwicklern einen Bericht senden, in dem Maßnahmen gefordert werden. Solche Fehler sollten von SystemError geerbt SystemError

Es gibt auch Validierungsfehler , auf die wir im nächsten Artikel näher eingehen werden.

Übungsgebrauch

1. Verwenden Sie Variablen, um die Lesbarkeit zu verbessern

 module Fishing # bad -   Serivices::Catch.call(fish, rod) # bad -  Serivices::Catch.call(fish: fish, rod: rod) # good -   Serivices::Catch.call(fish, with: rod) module Serivices class Catch def initialize(fish, with:) @fish = fish @rod = with #      #   . end # ... private attr_reader :fish, :rod end end end 

2. Übergeben Sie Objekte, keine Parameter

Versuchen Sie, den Initialisierer einfach zu gestalten, wenn die Parameterverarbeitung nicht den Zweck hat.
Übergeben Sie Objekte, keine Parameter.

 module Service # bad -        -.  #      ,   . class Foo def initialize(foo_params:, bar_params:) @foo = Values::Foo.new(*foo_params) @bar = Values::Bar.new(*bar_params) end # ... end Services::Foo.call(foo: {a: 1, b: 2}, bar: 34) # good -   -. class Bar def initialize(foo:, bar:) @foo = foo @bar = bar # ... end end foo = Values::Foo.new(a: 1, b: 2) bar = Values::Bar.new(34) Services::Bar.call(foo: foo, bar: bar) # good -       - Builder. class BuildFoo def initialize(param_1:, param_2:) @param_1 = param_1 @param_1 = param_1 end def call Foo.new( param_1: param_1.foo, param_2: param_2.bar, param_3: some_magick ) end # ... end end 

3. Verwenden Sie den Namen Actions - das Verb der Aktion und das Objekt des Einflusses.

 # bad module Services class Milk; end class Work; end class FooBuild; end class PasswordGenerator; end end # good module Services class GetMilk; end class WorkOnTable; end class BuildFoo; end class GeneratePassword; end end 

4. Verwenden Sie nach Möglichkeit die Aufrufklassenmethode

Normalerweise eine Instanz der Actions- Klasse, die nur selten zum Schreiben verwendet wird, um einen Anruf zu tätigen.

 # good -    . Services::BuildFoo.call(params) # good -     Services::BuildFoo.(params) # good -   ,      , #    ,     ,   #  . ring = Services::RingToPhone.new(phone: neighbour) 10.times do ring.call end 

5. Die Fehlerbehandlung ist keine Serviceaufgabe

 # bad -    ,   . def call #... rescue SystemError => e return false end 

Module

Bis zu diesem Moment haben wir die Implementierung der Service-Schicht als eine Reihe von Funktionsobjekten betrachtet. Aber wir können leicht Methoden auf dieser Ebene platzieren:

 module Services def sum(a, b) a + b end end 

Ein weiteres Problem, mit dem wir konfrontiert sind, ist eine große Anzahl von Serviceeinrichtungen. Anstelle des "Rails Fat Model", das wir auf den neuesten Stand gebracht haben, erhalten wir den "Services Fat Folder". Es gibt verschiedene Möglichkeiten, die Struktur zu organisieren, um das Ausmaß der Tragödie zu verringern. Eric Evans löst dieses Problem, indem er eine Reihe von Funktionen in einer Klasse kombiniert. Stellen Sie sich vor, wir müssen die Geschäftsprozesse des Kindermädchens Arina Rodionovna modellieren, sie kann Puschkin füttern und ihn ins Bett bringen:

 class NoonService def initialize(arina_radionovna, pushkin) # ... end def to_feed # ... end def to_sleep # ... end end 

Dieser Ansatz ist aus Sicht von OOP korrekter. Wir empfehlen jedoch, es zumindest in der Anfangsphase aufzugeben. Nicht sehr erfahrene Programmierer beginnen in dieser Klasse viel Code zu schreiben, was letztendlich zu einer erhöhten Konnektivität führt. Stattdessen können Sie das Modul verwenden, das die Aktivität als eine Abstraktion darstellt:

 module Services module Noon class ToFeed def call! # ... end end class << self #    ,   #    def to_feed(arina_radionovna, pushkin) ToFeed.new(arina_radionovna, pushkin).call end #    ,    def to_sleep(arina_radionovna, pushkin) arina_radionovna.tell_story pushkin pushkin.state = :sleep end end end end 

Bei der Aufteilung in Module sollte eine niedrige externe Kopplung (niedrige Kopplung) mit hoher interner Kohäsion (hohe Kohäsion) beobachtet werden. Wir verwenden jedoch Module wie Services oder Interactors. Dies widerspricht auch den Vorstellungen einer reinen Architektur. Dies ist eine bewusste Entscheidung, die die Wahrnehmung erleichtert. Unter dem Namen der Datei verstehen wir, welches Entwurfsmuster diese oder jene Klasse implementiert. Wenn dies für einen erfahrenen Programmierer offensichtlich ist, ist dies für einen Anfänger nicht immer der Fall. Wenn Ihr Team bereit ist, verwerfen Sie diesen Überschuss.

Um einen weiteren kleinen Auszug aus dem großen blauen Buch zu zitieren:

Wählen Sie Module aus, die den Verlauf des Systems beschreiben und zusammenhängende Konzeptsätze enthalten. Daraus ergibt sich oft eine geringe Abhängigkeit der Module voneinander. Ist dies jedoch nicht der Fall, suchen Sie nach einer Möglichkeit, das Modell so zu ändern, dass die Konzepte voneinander getrennt werden, oder suchen Sie nach dem im Modell fehlenden Konzept, das die Grundlage für das Modul bilden und die Elemente des Modells auf natürliche und sinnvolle Weise zusammenführen könnte. Erzielen Sie eine geringe Abhängigkeit der Module voneinander in dem Sinne, dass Konzepte in verschiedenen Modulen unabhängig voneinander analysiert und wahrgenommen werden können. Verfeinern Sie das Modell, bis darin natürliche Grenzen gemäß den übergeordneten Konzepten des Themenbereichs angezeigt werden und der entsprechende Code nicht entsprechend unterteilt ist.

Geben Sie die Modulnamen an, die in der UNIFIED LANGUAGE enthalten sein sollen. Sowohl die MODULE selbst als auch ihre Namen sollten das Wissen und das Verständnis des Themenbereichs widerspiegeln.

Das Thema Module ist groß und interessant, geht aber deutlich über das Thema dieses Artikels hinaus. Nächstes Mal werden wir mit Ihnen über Repositories und Adapter sprechen. Wir haben einen gemütlichen Telegrammkanal eröffnet, in dem wir Materialien zum Thema DDD austauschen möchten. Wir freuen uns über Ihre Fragen und Ihr Feedback.