Bei NORBIT beschäftigen wir uns mit SRM-Lösungen . Heute erzählen wir Ihnen von einem speziellen Projekt für unser Team - der Entwicklung der NBT BPMS-Plattform. Wir haben nicht nur eine Geschäftslösung für den Kunden erstellt, sondern unser eigenes Produkt von Grund auf neu entwickelt. All dies impliziert einen völlig anderen Ansatz für Design, Entwicklung, Teammanagement, Organisation von Änderungslieferprozessen und Release-Planung.
Im Allgemeinen handelt der Artikel nicht nur vom schönen KDPV. Sie werden auch lernen:
- über unsere Erfahrungen beim Entwerfen von Microservice-Architekturen (Auswahl der Tools, Ansätze zur Verwendung dieser Tools, nämlich Abstraktion ihrer Verwendung);
- über die Entwicklung eines Designers von Geschäftsobjekten und die Implementierung eines Designers von Geschäftsprozessen in die Lösung, um den Ansatz der Low-Code-Entwicklung sicherzustellen;
- darüber, wie wir die Arbeit am Projekt organisiert und die Entwickler vor einigen routinemäßigen oder ablenkenden Aspekten bei der Arbeit am System bewahrt haben (abstrakte Interaktionen zwischen Diensten, automatische Codegenerierung, Teamatmosphäre);
- und darüber, welches Mem uns in schwierigen Zeiten geholfen hat.
Unsere Abteilung im Unternehmen NORBIT befasst sich hauptsächlich mit der Automatisierung von Beschaffungsprozessen, für die verschiedene Arten von Lösungen auf der .Net-Plattform erstellt werden.
Die Entwicklung solcher Lösungen begann mit ASP.NET WebForms. Anschließend wurden neue Versionen dieser Lösungen auf der Basis von ASP.NET MVC erstellt. Neben der Entwicklung in .NET hatten und haben wir noch andere Projekte und Lösungen. Dennoch macht die Entwicklung in .NET etwa 80% aller Projekte der Abteilung aus.
Die Einschränkungen von ASP.NET WebForms und ASP.NET MVC legen nahe, dass für die Funktionen der Lösungen auf diesen Plattformen die Bereitstellung auf einem Betriebssystem der Windows Server-Familie erforderlich war und auf der DB-Seite (Datenbank) ein Logikvolumen implementiert wurde, das keinen schnellen und schmerzlosen Übergang ermöglichte auf einem anderen DBMS als MS SQL Server. Dies war vor Beginn des massiven Übergangs zu inländischer Software kein Hindernis und keine Schwierigkeit.
Von 2014 bis 2015 begann sich der IT-Markt sehr ernsthaft in Richtung Importsubstitution zu bewegen, und das Problem der Bereitstellung unserer Systeme auf Betriebssystemen und DBMS, die den neuen Anforderungen entsprechen würden, war ziemlich akut. In der Tat wurde es Frage Nummer 1dass wir lösen mussten, damit unsere Lösungen langfristig die Anforderungen potenzieller Kunden abdecken konnten.
Gleichzeitig schien es nicht sinnvoll, mit starken Kompetenzen und einem ziemlich großen Team von .NET-Entwicklern einen neuen plattformübergreifenden Kernel zu entwickeln, der nicht auf .NET basiert. Die Veröffentlichung der Open Source .NET Core-Plattform war für uns sehr willkommen, auch aufgrund ihrer Kompatibilität mit Betriebssystemen wie Windows, Linux und macOS.
Frage Nummer 2 , die wir lösen mussten, war, dass die meisten zuvor erstellten Lösungen eine obligatorische Programmierung voraussetzten, um Attribute von Geschäftsobjekten hinzuzufügen oder Geschäftsprozesse im System zu ändern.
Es ist mit zwei Aspekten verbunden.
- ( ) - , , , . , , - , , -.
- Low-code development, , , « » - -.
Und Frage Nummer 3 , mit der wir seit vielen Jahren konfrontiert sind, ist die Unvollkommenheit der Architekturen der zu erstellenden Systeme, die es uns nicht ermöglicht, einen Teil schnell neu zu schreiben, ohne einzelne Module neu schreiben zu müssen, oder eine ausreichend hohe Einstiegsschwelle für Programmierer, Analysten und Tester beim Herstellen einer Verbindung schafft Projekte.
Am Eingang des Projekts gab es viele weitere Fragen und Probleme, die später besprochen werden. Aber diese drei (Importsubstitution und Open Source, Low-Code, niedrige Einstiegsschwelle und schnelle Immersionsrate neuer Teammitglieder) betrachten wir als die wichtigsten, die wir lösen mussten.
Design
Das Nachdenken über diese Fragen führte uns zu der Erkenntnis, dass wir eine Art Konstruktor benötigen, mit dem Analysten ein System (Geschäftsobjekte und Geschäftsprozesse) nach den Bedürfnissen des Kunden "spielen" und entwerfen können. Es klingt gewagt, ist aber viel interessanter als ein anderes System für einen Kunden zu schreiben. Tatsächlich haben wir uns entschlossen, unser Produkt in Form eines Konstrukteurs herzustellen und zu entwickeln.
Wir haben uns definitiv nichts Revolutionäres ausgedacht, und es gibt viele ähnliche Produkte auf dem Markt, aber es war für uns von grundlegender Bedeutung, unsere angesammelten Fragen zu lösen, zumal es aus den zuvor genannten Gründen für uns, gelinde gesagt, schwierig war, den Weg der Umgestaltung bestehender Systeme zu beschreiten.
In der Entwurfsphase mussten wir die Tatsache überdenken, dass wir nicht immer im Voraus wissen, wer unser potenzieller Kunde ist, ob groß oder klein, anspruchsvoll oder loyal, welche Geschäftsprozesse er hat, welche Art von Infrastruktur. Einige der Anforderungen an das zukünftige System stellten sich von selbst heraus: Sie benötigen eine Skalierung, Sie benötigen eine plattformübergreifende Anpassung, Sie benötigen eine flexible und schnelle Anpassung von Geschäftsobjekten / Geschäftsprozessen, eine Schnittstelle, wahrscheinlich einen "Wagen und einen kleinen Wagen" mit Integrationen. Es wurde beängstigend, sehr beängstigend.
Aber wie einer unserer Teamleiter sagt: "Der Elefant muss Stück für Stück gefressen werden, beginnend mit dem Fuß." In dieser Phase haben wir uns zwei Aufgaben gestellt: die Auswahl der Microservice-Architektur und die Auswahl der Tools. Ja, sofort nur Microservice (Martin Fowler empfiehlt MonolithFirst , aber wir haben beschlossen, ihm nicht zu gehorchen), denn mit Monolithen sind wir schon lange auf "Ihnen" und es ist Zeit, die Herausforderung anzunehmen, um weiterzumachen. Im Ernst, die Forderung nach horizontaler Skalierung des Systems allein reicht unserer Meinung nach völlig aus.
Auswahl an Architektur und Werkzeugen
Bei der Gestaltung der Architektur haben wir mehrere Ziele verfolgt:
- Abstraktion der verwendeten Werkzeuge, um jederzeit ein ungeeignetes Werkzeug durch ein anderes ersetzen zu können;
- ( , );
- , .
Da unser Team auf Microsoft-Technologien spezialisiert ist, wurde .NET Core Version 2.1 als Implementierungsplattform ausgewählt. Zu Beginn der Entwicklung unseres Produkts war diese Version LTS (Langzeitunterstützung), und für uns war dies ein wichtiges Kriterium, da einige inländische Betriebssysteme (auf denen wir das System möglicherweise bereitstellen könnten) nur .NET Core LTS-Versionen unterstützen ...
Sie haben beschlossen, Frontend in React + TypeScript zu erstellen, da es leicht zu erlernen ist. Wir haben uns entschlossen, den Full-Stack-Ansatz der Entwickler zu fördern.
Wir haben uns entschlossen, die dienstübergreifende Kommunikation synchron zu gestalten, weil unsere Anrufketten eigentlich kurz sein sollten und die dienstübergreifende Kommunikation immer noch abstrahiert ist. Ein Dienst ruft einen anderen Dienst über einen abstrakten Proxy auf. Und es kann jede Logik enthalten. In unserem Fall ist dies ein Aufruf eines anderen Dienstes über http über Service Discovery. Dieses Design ermöglichte es uns einerseits, das Leben der Entwickler zu vereinfachen (sie können es einfach über die Dienstschnittstelle aufrufen, aber im ASP.NET Core-Dienstcontainer ist die registrierte Implementierung dieser Schnittstelle derselbe Proxy) und andererseits - Automatische horizontale Skalierung des Systems, da wir Service Discovery immer fragen, wie ein Dienst aufgerufen werden soll, und dies wiederum eine der laufenden Instanzen dieses Dienstes ergeben kann.
Irgendwann wurde die Struktur des Dienstes zum Standard, und wir haben Erweiterungen für Visual Studio vorgenommen, die beim Hinzufügen eines neuen Projekts zur Lösung wieder eine Projektstruktur mit einer minimalen Implementierung des Dienstes generieren, sodass Entwickler diese Routine nicht ausführen müssen. Darüber hinaus haben wir mehrere Skripte erstellt, um das gesamte System mit einer leichten Handbewegung zu starten (später haben wir über die gleiche schnelle Bereitstellung eines leichten Orchestrators durch den Entwickler nachgedacht).
Das Auswahlverfahren war auch sehr interessant. Wir mussten entscheiden, welche Funktionen wir selbst schreiben und welche "out of the box" (über vorhandene Tools sprechen), aber natürlich alle Interaktionen damit abstrahieren, damit dieses Tool oder diese Bibliothek bei Bedarf durch eine andere Implementierung ersetzt werden kann. Wir brauchten die folgenden Tools: Suchmaschine, Geschäftsprozessmaschine (BPMN Engine), Service Discovery-Protokoll (Service Discovery), Scheduler. Die Kriterien waren unterschiedlich: Lizenzen, Arbeitsgeschwindigkeit, Geschwindigkeit des Eintauchens des Projektteams usw. Das Ergebnis ist die folgende Liste: Elasticsearch, Camunda, Consul, Hangfire.
Sofort legten sie Unterstützung für mindestens PostgreSQL und SQL Server fest, konzentrierten sich jedoch hauptsächlich auf PostgreSQL und die Bereitstellung unter Linux. Freie Software, wissen Sie. In dieser Hinsicht geschah eine merkwürdige Geschichte. Wir haben die Unterstützung für SQL Server frühzeitig festgelegt, aber nicht wirklich erwartet, dass einige unserer potenziellen Kunden an einer Bereitstellung unter Windows + SQL Server interessiert sind. Daher haben wir das Testen dieser Konfiguration auf einen späteren Zeitpunkt verschoben (schließlich ist immer im Voraus bekannt, in welcher Umgebung sich der Kunde befindet ?!). ... Und dann, eines Tages, als wir einen weiteren Teststand für einen potenziellen Kunden erstellten, waren wir bereits bereit, AltLinux + PostgreSQL wie gewohnt bereitzustellen, aber plötzlich stellen wir fest, dass der Kunde seine Meinung geändert und beschlossen hat, auf Windows + SQL Server bereitzustellen, und wir haben zwei Tage Zeit, um alles zu tun bereiten. Glücklicherweise war der lange geschriebene und vergessene Code nützlich.Wer hat uns diese Unterstützung mit geringfügigen Verbesserungen zur Verfügung gestellt, und wir haben es geschafft, alles rechtzeitig vorzubereiten, und das System hat so funktioniert, als wäre nichts passiert (Ruhm für .NET Core).
Umsetzung von Geschäftsideen
Wir näherten uns der Implementierung mit einer vorbereiteten Liste von Arbeitsschritten, und das wichtigste davon war, in naher Zukunft MVP (Minimum Viable Product) zu erhalten. Fast von den ersten Iterationen an haben wir begonnen, mit dem Schwerpunkt darauf zu arbeiten, so schnell wie möglich einen Prototyp mit einem visuellen Teil zu erhalten, der den Kunden (die zu Beginn unsere Marktführer waren) regelmäßig demonstriert werden kann. Dieser Ansatz trug erwartungsgemäß dazu bei, einige der zuvor konzipierten Konzepte zu überdenken. Ich habe es geschafft, einige Widersprüche aufzufangen und sie im Voraus zu bekämpfen. Es geht darum, eine Web-API für die Frontend- und Backend-Kommunikation zu entwerfen.
Geschäftsobjektkonstruktor
Es wurde bereits oben erwähnt, dass eine der Schlüsselideen des Produkts die Fähigkeit ist, eine Geschäftsobjektstruktur durch einen Konfiguratorbenutzer zu erstellen. Wir haben tatsächlich mit der Implementierung des Konstruktors von Geschäftsobjekten begonnen. Die ersten Versionen waren natürlich konzeptioneller, aber sie gaben uns später reichhaltige Denkanstöße. Die einst einfachen Geschäftsobjekte mit einigen einfachen Feldern haben sich anschließend zu mehrstufigen multifunktionalen Einheiten mit einer Vielzahl von Einstellungen aller Art entwickelt. Wir haben gelernt, wie Sie nicht nur einfache Felder anpassen, sondern auch Felder mit einer Auswahl aus hierarchischen Verzeichnissen, zugehörigen Sammlungen von Objekten mit Filterung usw.
Das von der Maus des Konfigurators generierte Geschäftsobjekt verfügt über genügend Metadaten, um benutzerdefinierte durchsuchbare Register und verschiedene Präsentationsformulare erfassen zu können.
Das Problem der Validierung von Geschäftsobjekten hat uns auch nicht verschont. Wir haben schnell festgestellt, dass die Validierung nur von der Geschäftslogik begleitet werden kann, die zum Zeitpunkt des Füllens des Geschäftsobjekts mit Daten erforderlich ist. "Wenn" Feld 1 "" Wert 1 "hat, muss" Feld 2 "ausgeblendet werden" oder "Feld 1 ist die Summe von Feld 2 und Feld 3" sind nur einige der einfachsten Beispiele, die angegeben werden können. Wie lange ist es kurz, und wir haben jetzt eine Ereignis-Engine, in der ein solches Verhalten konfiguriert werden kann. Ereignisse können auch mit der Maus konfiguriert werden. Viele Optionen wurden bereits implementiert, einschließlich komplexer Berechnungen. Dies ist jedoch ein Thema für ein anderes Gespräch. Bitte schreiben Sie in die Kommentare, wenn Sie ein ähnliches Problem gelöst haben, wäre es interessant, Gefühle auszutauschen.
Geschäftsprozess-Designer
Wie wir gerne wiederholen: "Wer braucht Geschäftsobjekte ohne Geschäftsprozesse?"
Ergebnisse
Seit Beginn des Projekts sind anderthalb Jahre vergangen. Das Team hat sich verzehnfacht, die
Das erste, was mega-cool erscheint, ist die Tatsache, dass je mehr Funktionalität wir machen, desto mehr Ideen bekommen wir. Es fühlt sich so an, als würden wir uns nicht vom Beginn des Projekts bis zu seiner Fertigstellung bewegen, sondern einfach von Anfang an und weiter - dies ist ein wichtiger Aspekt. Nach vielen Jahren der Unterstützung vorgefertigter Lösungen (und dies kommt im Leben eines IT-Spezialisten sehr häufig vor) ist dieser Sachverhalt sehr motivierend.
ZweiteMega-Feeling ist es, ein so motiviertes Team zu beobachten und dabei zu sein. Der Prozess der Erstellung eines neuen Produkts besteht nicht nur aus einer Abfolge von Aufgaben und Phasen. Dies ist vor allem die Atmosphäre. Die Atmosphäre der Tatsache, dass Sie sehr oft das tun, was Sie noch nie getan haben, obwohl Sie an Dutzenden von Projekten teilgenommen haben. Jedes Teammitglied atmet es und merkt irgendwann, dass es nach dem ersten Atemzug die Komfortzone verlassen hat. Die schwierigste und wichtigste Aufgabe ist es, diese Atmosphäre frisch, komfortabel und interessant zu gestalten. Wir können uns nicht vor Fehlern, Fristen usw. verstecken, aber das Fehlen einer unterstützenden Umgebung, in der wir uns alle befinden, kann viel zerstörerischer sein.
Wir versuchen, dem Entwicklungsprozess unseres Produkts besondere Aufmerksamkeit zu widmen. Dieser Prozess ist nicht statisch. Er macht bei Bedarf Änderungen durch, macht es aber möglich, seine Probleme bequem zu lösen und seinen Kollegen dabei zu helfen.
PS Es ist schwierig, alles in einem Artikel detailliert zu beschreiben, daher stellte sich heraus, dass es mehr Übersicht gab. Wir hoffen sehr, dass Sie etwas Interessantes darin gefunden haben, und beantworten gerne Ihre Fragen in den Kommentaren oder beschreiben einige Aspekte unseres Systems in einem separaten Artikel ausführlicher.