前回の記事「 AO エコシステムにおける勝利の鍵: Web3 時代のマイクロサービス アーキテクチャ」では、アクター モデルの利点とそれがアプリケーション開発にもたらす複雑さについて説明しました。 「複雑さ」を解決するために、Web3 開発者は、開発方法論、開発ツール、ソフトウェア エンジニアリングの実践など、「大量採用」を達成した Web2 から学び続ける必要があります。次の記事では、考えられる方法の 1 つについて説明します。それは、「ローコード開発プラットフォーム」への投資を増やし、アプリケーション開発の「複雑さ」のかなりの部分をローコード プラットフォームに移管し、アプリケーション開発者がより集中できるようにすることです。ビジネスロジックの実現。
著者:楊潔峰 @ArweaveOasis
レビュー者:レモン
出典:コンテンツ ギルド - ニュース
前回の記事「 AO エコシステムにおける勝利の鍵: Web3 時代のマイクロサービス アーキテクチャ」では、マイクロサービス アーキテクチャ (またはアクター モデル) を採用する利点と、それがアプリケーション開発にもたらす複雑さについて説明しました。同時に、パブリックチェーンをめぐる戦いは実際にはアプリケーション開発者にとっての戦争であることも最後に述べられました。では、このように競争の激しいパブリック チェーン トラックにおいて、AO はどのようにして開発者に勝つことができるのでしょうか?
もちろん、「大量採用」を達成した Web2 から学び続けてください。これには、インフラストラクチャの学習だけでなく、開発方法論、開発ツール、ソフトウェア エンジニアリングの実践などの側面も含まれます。
ローコード開発プラットフォームは、間違いなく Web3 分野で多大な投資を行う価値のある方向性です。私が言いたいのは、アプリケーション開発の「複雑さ」のかなりの部分をローコード プラットフォームに移行できるということです。
ローコード開発プラットフォームとは何ですか?
まず、ローコード (ローコード) とノーコード (コードなし) の違いを明確にしたいと思います。もちろん、これは単なる私の個人的な意見です。
- ローコードはプロの開発者を対象としています。 業界は、ローコード プラットフォームが持つべきコア機能についてコンセンサス (事実上の標準) に達しました。 肝心なのは、「モデル駆動型」のアプローチを取る必要があるということです。
- ノーコードとは、「エンド ユーザー」を対象とした幅広いカテゴリのツールを指します。 ノーコードとは何かについて、業界に統一された基準はありません。 これらを使用すると、ユーザーは製品広告ページ、オンライン調査、個人ブログなどの簡単なアプリケーションを作成できます。 これまで開発者が必要と考えられていた特定のタスクを、特定のツールを使用して一般ユーザーが完了できるようになった限り、そのツールはノーコードと呼ばれます。
ローコード VS ノーコード
では、私が話しているローコード プラットフォームの「事実上の標準」とは何でしょうか?ここの説明を参照してください。
「フォーム駆動型」ローコード プラットフォームや「テーブル駆動型」ローコード プラットフォームについて聞いたことがあるかもしれませんが、ここでは特に「モデル駆動型」ローコード プラットフォームについて言及します。私の説明は、「ローコード プラットフォーム」の概念の狭い解釈として解釈できます。
従来のアプリケーション用のローコード開発プラットフォームは、成熟の初期段階に入っています。 「『モデル駆動』の Web3 ローコード開発プラットフォームについては聞いたことがないような気がします。」と言う人もいるかもしれません。確かに、これは比較的珍しいことです。その理由を分析してみましょう。
まず第一に、なぜ従来のローコード プラットフォームが Web3 分野に参入してこなかったのでしょうか?それは主に、彼らが使用しているモデリング パラダイムが Web3 に適用されないためだと思います。
従来のエンタープライズ プラットフォームは、ER モデルやリレーショナル モデルを使用します。 たとえば、 OutSystems はER モデルとリレーショナル モデルの両方を使用しますが、プラットフォームによってはどちらか一方のみを使用することもあります。 ER モデルとリレーショナル モデルは概念的に似ています。 これらのプラットフォームは、SQL データベースなどの従来のエンタープライズ ソフトウェア インフラストラクチャ上で実行できるコードを生成します。 しかし、ブロックチェーン上の「分散型台帳」は SQL データベースとはあまりにも異なるため、ブロックチェーンなどの Web3 インフラストラクチャ上で実行するのは困難です。
では、分散型アプリケーション用の既存の「ローコード プラットフォーム」はどのように機能するのでしょうか?
真のローコード プラットフォームを開発すること、特にモデル駆動型アプローチを使用することは、簡単な作業ではありません。この難しい仕事を敬遠したくなる人もいるかもしれません。 ただし、プロフェッショナルなローコード プラットフォームのコア機能は、他のソリューションにはない独自の価値を提供します。 たとえば、「構成可能なスマート コントラクト テンプレート」は、開発者が「既成のコード」をより速くコピーするのに役立ちますが、これらの革新的なアプリケーションの場合、これらのテンプレートはあまり役に立ちません。 また、プラットフォーム開発者にとって、複数のチェーンに適した「スマート コントラクト テンプレート」のライブラリを異なる言語 (Solidity、Move など) で作成して維持することは大きな課題です。 さらに、「スマート コントラクト」はアプリケーションのオンチェーン部分にすぎず、やや大規模な分散アプリケーションではオフチェーン部分も必要になることがよくあります。
dddappp: 真の Web3 ローコード開発プラットフォーム
では、「モデル駆動型」アプローチを採用し、いたずらをせず、課題に正面から取り組む「本物の」Web3 ローコード開発プラットフォームは存在するのでしょうか?
私のチームが開発したdddappp が、分散型アプリケーションのための真のローコード開発プラットフォームであることを発表できることを非常に誇りに思います。これはおそらく、「モデル駆動型」アプローチを採用する唯一の Web3 ローコード開発プラットフォームです。
では、dddappp の何がそんなにユニークなのでしょうか?他のプラットフォームでは (少なくとも一時的には) できないことがなぜできるのでしょうか?
鍵となるのは、dddappp が採用するモデリング パラダイムです。 DDD スタイルのドメイン モデルを選択しました。
DDD スタイルのドメイン モデルは、比較的高レベルの抽象的な OO (オブジェクト指向) モデルです。 自動化ツールは、このような高レベルのドメイン モデルを、オブジェクト指向プログラミング モデルやリレーショナル データ モデルなどの低レベルの実装モデルに簡単にマッピングできます。
「高度な抽象化」とは何ですか? このように言い換えると、技術的な詳細で問題を「どのように」解決するかではなく、その分野について「何を」知っているかを可能な限り表現するのに役立ちます。
経験豊富な開発者は、これが言うは易く行うは難しであることをすぐに理解するでしょう。 私たちはこれを完全に偶然に行うことができ、2016 年からこの分野で豊富な経験を蓄積してきました。 私たちは開発者と経験を共有するために本を書きました。
経験豊富な開発者は、これが言うは易く行うは難しであることをすぐに理解するでしょう。 私たちはこれを完全に偶然に行うことができ、2016 年からこの分野で豊富な経験を蓄積してきました。 私たちは開発者と経験を共有するために本を書きました。
重要なのは、DDDML (Domain-Driven Design Modeling Language の頭字語) と呼ばれる、ドメイン モデリング用の非常に表現力豊かな DSL を発明したことです。 これを使用すると、ドメイン知識を正確に記述できるだけでなく、これらのモデルをソフトウェア実装コードに簡単にマッピングすることもできます。
ちなみに、当社の DSL は他の「競合他社」よりも問題領域と自然言語に近いため、人工知能 (AI) と完全に統合できると考えています。
私たち自身は、DDDML を常に「DDD ネイティブ DSL」と呼んでいます。
前に述べた DDD の「集約」の概念を覚えていますか? 私たちが使用する DSL は、最初から集計の定義をサポートしています。DDDML モデル ファイルを開くと、キーワード集計がほぼ表示されます。
DDD の関連概念に精通している場合は、DDDML で説明されるモデルを簡単に理解できます。DDD に詳しくない場合でも、DDD には古典的な作品における体系的な議論と、後追いするファンの実践の両方があります。時代とともに、あなたが「理解する」意欲さえあれば、それらはすぐに手に入るのです。
DDD 方法論の強力な基盤には、しばしば驚かされます。 従来のアプリケーション (バックエンドは主に Java または C# で記述されている) を開発する場合、開発効率を大幅に向上させる「ドメイン モデル駆動」アプローチを使用してきました。 Web3 という新しい世界に入ったとき、DDDML を使用すると、あまり多くのものを追加することなく、分散型アプリケーションの開発を推進できることがわかりました。
dddappp は AO エコロジカル アプリケーション開発にどのように役立ちますか?
この記事の前半では、AO を使用したアプリケーション開発の課題のいくつかについて説明しました。
では、dddappp が採用した技術ソリューションは、AO エコシステムの開発者に本当に役立つのでしょうか? AO に基づいて最近完了した概念実証を見てみましょう。
このデモンストレーションでは、いくつかの問題に対して非常に魅力的な解決策を提供できたと考えています。 DSL を使用して集約、値オブジェクト、およびサービス (これらは DDD の概念です) を定義する方法を示し、生成されたコードの一般的な外観を示しました。開発者が本当にツールを使わずに手動でこのコードを書くつもりかどうか想像できますか? 特に、生成されたコードがSAGAパターンを使用して「結果整合性」処理をエレガントに実装できる方法も示します。
このデモをPoCと呼んでいますが、実際にはPoCを超えていると思います。それは、AO エコシステムの開発者をすぐに助けることができるからです。 AO エコシステムの開発者は、これを使用してアプリケーション設計のアイデアを明確にし、コードを生成し (これらのコードは少なくとも実装リファレンスとして使用できます)、効率を向上させることができます。 ある程度、このツールは MVP (minimum viable product) であるとすでに言えます。 MVP の定義は、エンド ユーザーを支援し、エンド ユーザーにとって価値がある限り、MVP と呼ぶことができるためです。結局のところ、開発者はローコード ツールのエンド ユーザーです。
経験豊富なアプリケーション開発者がこの PoC を注意深く研究すれば、アプリケーション開発効率の向上におけるローコード手法の大きな可能性を疑う必要がなくなるはずです。 結局のところ、私たちはこれを AO エコシステムの外で何度も証明してきました。 Web2 時代に同じ手法を使用して開発した複雑な商用アプリケーションについて言及しなくても、Move エコシステムにおける当社の実践を観察するだけでも十分に説得力があります。
DSL を使用して、「インターフェイス」の抽象化が欠けている Move (静的スマート コントラクト言語) の制限を解決し、開発者が「依存関係の注入」を簡単に実装できるようにします。詳細については、この例を参照してください。
簡単な宣言で Move コントラクトを複数のパッケージ (つまり「プロジェクト」) に分割できます。この例を参照してください。 ほとんどの Move パブリック チェーンには、毎回リリースされるパッケージのサイズに制限があることに注意してください。
私たちが共有しているものは単なる「例」であり、単におもちゃを作っているだけかもしれないと考えているなら、それは完全に間違いです。
私たちが共有しているものは単なる「例」であり、単におもちゃを作っているだけかもしれないと思っているなら、それは完全に間違いです。
私たちは、いくつかの本格的な商用アプリケーション (主に Move エコシステムに焦点を当てた) の開発プロセスに深く関わってきました。このプロセスでは、ほとんど「自分たちのドッグフードを食べている」ような状態です。 現時点では、少なくともバックエンド (オンチェーン コントラクトとオフチェーン クエリ サービスを指します。後者はインデクサーと呼ばれることもあります) 開発領域では、10 の約束を果たしたと大きな自信を持って言えます。開発効率が倍増します。
当社は「ローコード」に基づいた「ノーコード」アプリケーションも開発しています (繰り返しになりますが、ノーコード ツールはエンド ユーザー向けのアプリケーションです)。 私たちは Aptos Singapore Hackathon で Move Forms と呼ばれるスピンオフ製品を構築し、現在のセッションで 2 位を獲得しました。 私たちは「余暇」にこの Web3 ネイティブ フォーム ツールを構築し続けます。
ご連絡いただければ、より多くの本番レベルの事例をご案内できます。私たちのケースには、ソーシャルネットワーキング、DeFi、フルチェーンゲームなどが含まれます。
多くの人は、ローコード プラットフォームで開発できる分散アプリケーションの種類について疑問を抱いているかもしれません。 正直に言うと、ローコード アプローチを使用して開発できるアプリケーションの種類に関して明らかな制限は見つかりませんでした。 アプリケーション開発の過程でより深く感じるのは、ローコードの限界よりも、現在のWeb3インフラの限界です。
興味深い現実を発見したかどうかはわかりません。一般に、従来のローコード プラットフォームはエンタープライズ ソフトウェア (OA、CRM、ERP など) の開発に適しており、開発には適していないと考えられています。インターネット アプリケーション; しかし、これまで見てきたことから、dddappp はこの制限を超えているようですね?あなたの感覚は正しいです。 これを Web2 時代、つまり Web2 時代では非常に大胆な試みであった DDD ドメイン モデルによるローコード プラットフォームで実現しようとした理由は、「ローコード プラットフォームで大規模な開発を可能にする」ためでした。インターネット アプリケーション。」
「AppCU」はAOエコシステムを開拓するブレークスルーとなる可能性がある
Lua と WASM の組み合わせは非常に優れていますが、正直に言うと、短期的には、伝統的に使用されている大規模な Web2 インターネット アプリケーション (Amazon、Taobao など) を統合するために Lua と WASM に依存することは想像できません。 Java、C#、PHP、Python などで書かれたもの、eBay、Shopee など)が AO に移行されました。
前述したように、AO はデータ プロトコルです。理論的には、誰もが好みのプログラミング言語を使用して独自の「実装」を開発し、AO ネットワークにアクセスして他のユニットと対話し、共同作業することができます。
AO ネットワークでは、アプリケーションのビジネス ロジックはコンピューティング ユニット (Compute Unit) で実行されます。 したがって、アプリケーション開発者が最も望んでいるのは、コンピューティング ユニットによってサポートされる開発スタックの多様性と包括性の向上です。 私の知る限り、AO 開発者コミュニティは、AO 上で実行される EVM スマート コントラクトのサポートなど、すでにこの方向に取り組んでいます。
しかし、この問題は別の方向で突破できる可能性があると思います。 AppCU は良いアイデアだと思います。 AppCU、つまりアプリケーション固有のコンピューティング ユニットを意味します。 Appchain ( アプリケーション固有のブロックチェーン) と類推すると、私の意味を理解するのに役立ちます。
コンピューティング ユニットを除外した場合、AO の他の部分は、ある程度、分散型メッセージ ブローカーである Kafka の Web3 バージョンとみなすことができます。 従来のアプリケーション開発者が、熟練した言語とツールを使用して、Kafka のようなメッセージ ブローカーに基づくマイクロサービス アーキテクチャ アプリケーションを開発できるようにします。「はは、これはよく知っています。」
AppCU をゼロから構築することは、ほとんどの開発者にとって簡単ではないかもしれません。Appchain の構築についても同様です。したがって、この場合、便利なツールが不可欠です。
Cosmosエコシステムの開発においてCosmos SDK (Appchain を構築するために使用されるツール) が果たす重要な役割を強調する必要はないと思います。
Cosmosエコシステムの開発においてCosmos SDK (Appchain を構築するために使用されるツール) が果たす重要な役割を強調する必要はないと思います。
Cosmos SDK を試したことのある開発者は、このツールの便利さと強力さに感銘を受けるでしょう。 Cosmos SDK がそれを実行できるのであれば、AO エコシステムの開発者コミュニティがそれを実行できない理由はありません。 いずれにせよ、チェーンよりもコンピューティング ユニットを開発する方が常に簡単ですよね?
Cosmos SDK は確かに「高効率」ツールですが、厳密に言えば、ローコード プラットフォームではありません。私たちは、ローコード プラットフォームには開発効率を向上させる大きな可能性があると信じています。
AI はローコード プラットフォームに取って代わるのでしょうか?
最後に、私が何度も答えてきた質問について話したいと思います。「AI はローコード プラットフォームを破壊するのでしょうか?」
私の意見では、近年の AI の目覚ましい進歩は、複雑なソフトウェア開発の方法論に根本的な変化をもたらしていません。 AI が複雑なアプリケーションの開発に関与している場合でも、人間と同じように「正しい」アプローチに従う必要があります。
ソフトウェア エンジニアリングのあらゆる抽象化レベルにはそれぞれの価値があります。 複雑なソフトウェアを開発するための最初の正しい「姿勢」は、最初にビジネス分析とドメイン モデリングを行うことです。 自然言語を使用すると「ドメインの認識」を正確に記述することができず、「ソフトウェアコードへの変換」の効率が大きく妨げられます。
dddappp の最もユニークな点は、dddappp が使用する DSL です。これにより、dddappp によって AI は自分が最も得意とすることに集中できるようになります。
1. AI は参照モデルを推奨し、モデルの反復を支援します。
- 私たちは自然言語を通じて AI とコミュニケーションをとることができ、AI にニーズを分析して参照モデルを推奨してもらうことができます。 AI は膨大な量の知識を持っており、それが得意です。
- AI はドメイン モデルを DSL として出力し、そのようなドメイン モデル (最小限の構文の正確さ) はツールを使用して検証できます。
- DSL の誤用がなく、ローコード ツールの実装にバグがなければ、モデルから生成されたコードの精度は 100% であると言えます。これは、「ワード ソリティア」を通じて生成 AI によって生成されたコードとは比較になりません。
- ローコード ツールは、モデルから直接実行可能アプリケーションを生成します。この段階では、モデリングでは「オブジェクト メソッド」(つまり、ビジネス ロジックの動作の詳細) を無視できます。生成されたアプリケーションはすぐに実行できます。
- ユーザーと開発者はまず「データモデル」を確認します。問題があれば AI にフィードバックし、AI にモデルの調整を手伝ってもらい、ローコード ツールでアプリケーションを再生成できます。
2. AIは「運用ビジネスロジック」の実装を支援します。
- モデルを決定した後、アプリケーション開発者は非常に具体的なコンテキストでビジネス ロジックをコーディングします。このような明確なコンテキストでは、IDE は高品質のプロンプトを簡単に生成して AI に送信でき、AI はコード スニペットで高精度に応答できます。
したがって、この質問に対する私の答えは「いいえ」です。少なくとも dddappp に関しては、この 2 つは互いにうまく補完し合うと考えています。
要約すると、ローコード開発プラットフォームの定義と、Web3 アプリケーション開発の複雑さを軽減するその大きな可能性を分析しました。ローコード プラットフォームの概念に基づいて、Cosmos SDK (Cosmos エコシステムで Appchain を構築するために使用されるツール) と同様の強力なツールを AO エコシステムに構築し、このツールを使用して AppCU を構築することで、開発時間を短縮できます。この複雑さは、AO エコシステムに大規模な導入を実現するための新しいアイデアと可能性ももたらします。
🏆 「バグを捕まえた」場合の賞品: この記事内でタイプミス、間違った文章、または間違った説明を見つけた場合は、 私をクリックして報告してください。インセンティブが与えられます。
免責事項: この記事は PermaDAO の見解や立場を表すものではありません。 PermaDAO は、投資アドバイスを提供したり、プロジェクトを推奨したりすることはありません。読者は、居住国の法律を遵守し、準拠して Web3 活動を行うことが求められます。
全てのコメント