クロスプラットフォームBPMSの開発方法

こんにちは！



NORBITではSRMソリューションを扱っています。今日は、私たちのチームのための特別なプロジェクト、NBTBPMSプラットフォームの開発についてお話します。私たちはお客様のためにビジネスソリューションを作成しただけでなく、独自の製品をゼロから開発しました。これはすべて、設計、開発、チーム管理、変更配信プロセスの編成、およびリリース計画に対するまったく異なるアプローチを意味します。 



一般的に、この記事は美しいKDPVだけではありません。また、次のことも学びます。

• マイクロサービスアーキテクチャの設計における私たちの経験について（ツールの選択、これらのツールを使用するためのアプローチ、つまり、それらの使用の抽象化）。
• ローコード開発のアプローチを確実にするための、ビジネスオブジェクトの設計者の開発およびソリューションにおけるビジネスプロセスの設計者の実装について。
• プロジェクトでの作業をどのように整理し、システムで作業するときに開発者を日常的な側面や気が散る側面から救ったかについて（抽象的なサービス間相互作用、コードの自動生成、チームの雰囲気）。
• そして、memeが困難な時期に私たちを助けてくれたことについて。

ソース



NORBIT 社の当社部門は、主に調達プロセスの自動化に取り組んでおり、.Netプラットフォーム上でさまざまな種類のソリューションを作成しています。 



このようなソリューションの開発はASP.NETWebFormsから始まり、ASP.NETMVCに基づいてこれらのソリューションの新しいバージョンが作成されました。.NETでの開発に加えて、他のプロジェクトやソリューションがあり、現在もありますが、それでも、.NETでの開発は、部門のすべてのプロジェクトの約80％を占めています。 



ASP.NETWebFormsとASP.NETMVCの両方の制限は、ソリューションがこれらのプラットフォームで機能するためには、Windows ServerファミリのOSでの展開が必要であり、DB（データベース）側では、迅速で痛みのない移行を可能にしない大量のロジックが実装されたことを示唆しています。 MS SQLServer以外のDBMS上。これは、国内ソフトウェアへの大規模な移行が始まる前に、障害や困難をもたらすものではありませんでした。 



2014年から2015年にかけて、IT市場は輸入代替に向けて非常に真剣に動き始め、新しい要件に適合するオペレーティングシステムとDBMSにシステムを展開するという問題は非常に深刻でした。実際、それは質問番号1になりました私たちのソリューションが潜在的な顧客の要件を長期的にカバーできるように解決する必要がありました。 



同時に、強力な能力と.NET開発者のかなり大きなチームを持っているため、.NET以外の新しいクロスプラットフォームカーネルの開発を開始することは合理的ではないように思われました。オープンソースの.NETCoreプラットフォームのリリースは、Windows、Linux、macOSなどのオペレーティングシステムとの互換性を含め、非常に歓迎されました。 解決する必要のある



質問2は、以前に作成されたソリューションのほとんどが、ビジネスオブジェクトの属性を追加したり、システムのビジネスプロセスを変更したりするための必須のプログラミングを想定していることでした。 



それは2つの側面に関連しています。

1. ( ) - , , , . , , - , , -. 
2. Low-code development, , , « » - -. 

そして、私たちが長年直面している質問3は、作成されているシステムのアーキテクチャの不完全性です。これは、個々のモジュールを書き直す必要なしに一部をすばやく書き直すことができないか、に接続するときにプログラマー、アナリスト、およびテスターに​​十分に高いエントリしきい値を作成します。プロジェクト。 



プロジェクトの入り口にはさらに多くの質問や問題がありましたが、これについては後で説明します。しかし、これら3つ（輸入代替とオープンソース、ローコード、低いエントリーしきい値、新しいチームメンバーの速い没入率）は、私たちが解決しなければならなかった重要なものを考慮します。 

設計

これらの質問を考えると、アナリストが顧客のニーズに応じてシステム（ビジネスオブジェクトとビジネスプロセス）を「操作」して設計できる一種のコンストラクターが必要であることがわかりました。大胆に聞こえますが、顧客向けに別のシステムを作成するよりもはるかに興味深いものです。実際、私たちは製品をコンストラクターの形で作成して開発することにしました。 



私たちは間違いなく革新的なものを思いついたわけではなく、同様の製品が市場に出回っていますが、特に前述の理由から、既存のシステムのリファクタリングの道をたどることが困難であったため、蓄積された質問を解決することが基本的に重要でした。 



設計段階では、潜在的な顧客が誰であるか、大小、要求が厳しいか忠実であるか、彼のビジネスプロセスは何か、インフラストラクチャの種類は常にわかっているとは限らないという事実を再考する必要がありました。将来のシステムの要件のいくつかは、独自に現れ始めました。スケーリングが必要であり、クロスプラットフォームが必要であり、ビジネスオブジェクト/ビジネスプロセスの柔軟で迅速なカスタマイズ、インターフェイス、おそらく統合の「ワゴンと小さなカート」が必要です。怖くてとても怖くなりました。



私たちのお気に入りの写真



しかし、私たちのチームリーダーの一人が言うように、「象は足から始めて少しずつ食べる必要があります」。この段階で、マイクロサービスアーキテクチャの選択とツールの選択という2つのタスクを設定します。はい、すぐにマイクロサービスを提供します（Martin FowlerはMonolithFirstを推奨しますが、私たちは彼に従わないことにしました）。モノリスでは長い間「あなた」であり、先に進むための挑戦を受け入れる時が来たからです。しかし、真剣に、私たちの意見では、システムの水平スケーリングの要件だけで十分です。

アーキテクチャとツールの選択

アーキテクチャを設計するとき、私たちはいくつかの目標を追求しました。 

1. 不適切なツールをいつでも別のツールに置き換えることができるようにするために使用されるツールの抽象化。
2. ( , );
3. , .

私たちのチームはMicrosoftテクノロジーを専門としているため、実装プラットフォームとして.NETCoreバージョン2.1が選択されました。当社の製品の開発が始まった時点では、このバージョンはLTS（長期サポート）でした。一部の国内オペレーティングシステム（システムを展開できる可能性がある）は.NET Core LTSバージョンのみをサポートするため、これは重要な基準でした。 ..。



習得が容易なため、React + TypeScriptでフロントエンドを作成することにしました。フルスタック開発者アプローチを推進することにしました。



サービス間通信を同期させることにしました、コールチェーンは短いはずであり、サービス間通信はまだ抽象化されているためです。サービスは、抽象プロキシを介して別のサービスを呼び出します。また、任意のロジックを含めることができます。私たちの場合、これはServiceDiscoveryを介したhttp経由の別のサービスへの呼び出しです。このような設計により、一方では開発者の生活を簡素化でき（開発者はサービスインターフェイスを使用して呼び出すことができますが、実際には、ASP.NET Coreサービスコンテナでは、このインターフェイスの登録済み実装は同じプロキシです）、他方では-システムの水平方向のスケーリングを自動的に提供します。これは、サービスの呼び出し方法を常にService Discoveryに要求するためです。これにより、このサービスの実行中のインスタンスの1つを提供できます。



ある時点で、サービス構造が標準になり、Visual Studioの拡張機能を作成しました。これは、新しいプロジェクトがソリューションに追加されると、最小限のサービス実装でプロジェクト構造を生成するため、開発者はこのルーチンを実行する必要がありません。これに加えて、手のわずかな動きでシステム全体を起動するためのいくつかのスクリプトを作成しました（後で、開発者からの軽量オーケストレーターの同じ迅速な展開について考えました）。



選考プロセスも非常に興味深いものでした。自分で作成する機能と「すぐに使用できる」機能（既存のツールについて説明する）を決定する必要がありましたが、もちろん、すべての相互作用を抽象化して、必要に応じて、このツールまたはライブラリを別の実装に置き換えることができるようにしました。次のツールが必要でした：検索エンジン、ビジネスプロセスエンジン（BPMNエンジン）、サービス検出プロトコル（サービス検出）、スケジューラー。基準は異なっていました：ライセンス、作業の速度、プロジェクトチームの没頭の速度など。結果は次のリストです：Elasticsearch、Camunda、Consul、Hangfire。



すぐに彼らは少なくともPostgreSQLとSQLServerのサポートを定めましたが、主にPostgreSQLとLinuxでの展開に焦点を合わせました。無料のソフトウェアですね。この点で、奇妙な話が起こりました。初期段階でSQLServerのサポートを開始しましたが、潜在的な顧客の一部がWindows + SQL Serverへの展開に関心を持つことを特に期待していなかったため、この構成のテストを後日まで延期しました（結局、顧客の環境は常に事前にわかっていますか？！） ..。そしてある日、潜在的な顧客のために別のテストスタンドを作成して、AltLinux + PostgreSQLを通常どおりに展開する準備ができていましたが、突然、顧客が気が変わってWindows + SQL Serverに展開することを決定したことがわかり、2日間ですべてを実行できます。準備します。幸いなことに、長く書かれていて忘れられていたコードが役に立ちました。マイナーな改善でこのサポートを提供してくれたので、すべてを時間どおりに準備することができ、システムは何も起こらなかったかのように機能しました（.NET Coreに栄光）。

ビジネスアイデアの実装

準備された作業段階のリストを使用して実装に取り​​組みましたが、その中で最も重要なのは、近い将来にMVP（最小実行可能製品）を取得することでした。ほぼ最初の反復から、視覚的な部分を備えたプロトタイプをできるだけ早く入手することに重点を置いて作業を開始しました。これは、顧客（最初はリーダーでした）に定期的にデモンストレーションできます。このアプローチは、予想通り、以前に考えられていた概念のいくつかの再考に貢献しました。私はなんとかいくつかの矛盾を見つけて、それらと前もって戦うことができました。フロントエンドとバックエンドの通信用のWebAPIを設計することです。

ビジネスオブジェクトコンストラクタ

この製品の重要なアイデアの1つは、コンフィギュレータユーザーがビジネスオブジェクト構造を作成する機能であることはすでに前述しました。実際には、ビジネスオブジェクトのコンストラクターの実装から始めました。もちろん、最初のバージョンはより概念的でしたが、その後、それらは私たちに豊かな思考の糧を与えてくれました。いくつかの単純なフィールドを持つかつて気取らなかったビジネスオブジェクトは、その後、あらゆる種類の設定の広い範囲を持つマルチレベルの多機能ユニットに進化しました。単純なフィールドだけでなく、階層ディレクトリから選択したフィールド、フィルタリングを使用して関連するオブジェクトのコレクションなどをカスタマイズする方法も学びました。



コンフィギュレータのマウスによって生成されたビジネスオブジェクトには、カスタムの検索可能なレジストリやさまざまな表示フォームを収集するのに十分なメタデータがあります。 



- ().



.



— , -

ビジネスオブジェクトの検証の問題も私たちを免れませんでした。検証には、ビジネスオブジェクトにデータを入力する段階で必要なビジネスロジックを伴わざるを得ないことがすぐにわかりました。「「フィールド1」に「値1」がある場合、「フィールド2」は非表示にする必要があります」または「フィールド1はフィールド2とフィールド3の合計です」は、挙げることができる最も単純な例のほんの一部です。どれくらい短いので、そのような動作を構成できるイベントエンジンができました。イベントはマウスで設定することもできます。複雑な計算を含む多くのオプションがすでに実装されています。しかし、これは別の会話のトピックです。同様の問題を解決した場合は、コメントに書き込んでください。感情を交換するのは興味深いことです。



フィールドのイベントを設定します（検証、条件、または計算の場合があります）

ビジネスプロセスデザイナー

繰り返しますが、「ビジネスプロセスのないビジネスオブジェクトが必要なのは誰ですか？」否や言うほどない。もちろん、ビジネスプロセスの問題を解決する必要がある時が来ることを事前に知っていました、そして私たちがそれに取り組まない限り、この恐ろしい仕事はまさに神秘的で神秘的なものでした。いくつかのミートアップを訪れ、いくつかの楽器を読んで試した後、神秘主義は消えました。Camundaエンジンを使用することが決定されました（もちろん、このツールへのアクセスを抽象化するためのすべての手順に従った後）。これは、私たちがユースケースで学び、成長し続ける素晴らしいツールです。



ビジネスプロセスにおけるビジネスオブジェクトの現在の位置

結果

プロジェクト開始から1年半が経過しました。チームは10倍に増え、髭の白髪の数も増え、何千もの問題が解決され、何百もの毎日の会議が開かれ、何千ものプルリクエストが注がれましたが、私はこれではなく、これを自慢したいと思います。



最初に非常にクールに思えるのは、機能を増やすほど、より多くのアイデアが得られるという事実です。プロジェクトの最初から完了までではなく、単に最初からさらに進んでいるように感じます。これは重要な側面です。既製のソリューションを長年サポートしてきた後（これはITスペシャリストの生活の中で非常に頻繁に発生します）、この状況は非常にやる気を起こさせます。



2番目メガフィーリングとは、そのようなやる気のあるチームを見て、その中にいることです。新製品を作成するプロセスは、一連のタスクと段階だけではありません。これがまずの雰囲気です。数十のプロジェクトに参加したことはありますが、今までやったことのないことを頻繁に行うという雰囲気。チームのすべてのメンバーがそれを呼吸し、ある時点で、彼が最初の呼吸の後にコンフォートゾーンを離れたことに気づきます。そして、最も困難で主なタスクは、この雰囲気を新鮮で快適で興味深いものにすることです。バグや締め切りなどから身を隠すことはできませんが、私たち全員が自分自身を見つける支援的な環境の欠如は、はるかに破壊的である可能性があります。



当社は、製品の開発プロセスに特別な注意を払うよう努めています。このプロセスは静的ではありません。彼は必要に応じて変更を加えますが、彼は問題を快適に解決し、同僚がそれを行うのを助けることを可能にします。



PS 1つの記事ですべてを詳細に説明することは難しいため、より概要がわかりました。何かおもしろいものを見つけていただければ幸いです。コメントで質問にお答えしたり、システムの一部の側面について別の記事で詳しく説明したりできます。