シンプルな請求システム (ColdBox MVC の上) は、セミエンタープライズ インベントリ + プロビジョニング + 問題追跡 + 利益追跡アプリに膨らんでいます。彼らは独自のことをしているように見えますが、クライアントとスタッフ (ログイン) の共通プール、およびその他の混在するデータとビジネス ロジックなど、多くのことを共有しています。
このようなシステムをどのようにモジュール化していますか? メンテナンス、テスト容易性、再利用性の観点から?
共有したいアイデアや経験はありますか?
ColdBox モジュールを使用して、アプリをモジュールに分割することをお勧めします。別のビジネス ロジックを RESTful ColdBox レイヤーに調査し、その方法でシステムに参加することもできます。繰り返しますが、それはすべて、現時点での要件とニーズによって異なります。
モジュールは、モノリシック アプリケーションをスタンドアロンまたは結合可能な、より管理しやすい部分に分割するように設計されています。
テクノロジ (Java ポータル、ColdBox モジュールなど) について考えるのをやめて、アーキテクチャに集中してください。これは、自分のシステムをオブザーバーに説明する方法を想像することを意味します。在庫、クライアント、問題追跡などの各部分を表す一連のボックスをホワイトボードに描くことから始めて、線を使用してこれらのシステム間の相互作用を示します。これは、機能のようにグループ化する懸念の分離に焦点を当てています。まず、UI について心配する必要はありません。代わりに、アルゴリズムとデータに注目してください。
MVC について話している場合、そのステップはモデルに焦点を当てています。そのアクティビティが完了すると、そのダイアグラム (つまりモデル) に適合するようにコードを変更するという難しい部分がやってきます。このモデルがどのようなものであるべきかを本当に理解するには、Eric EvansによるDomain Driven Designを読むことをお勧めします。目標は、依存性注入によって関係を管理できるモデルに到達することです。おそらく、これにより、基礎となるビジネスエンティティと永続性管理を備えた一連の高レベルの CFC (必要に応じてサービス) が残ります。それらの関係は、ある種の Bean コンテナー/サービス ロケーターによって最適に管理されます。ColdBox には独自のものがあると思います。別の例として ColdSpring があります。
この取り組みの成果は、単体テスト可能なモデルです。ユーザー インターフェイスから独立しています。これらすべてが混乱を招く場合は、この移行を行う方法についていくつかのアイデアについて、レガシー コードを効果的に使用する方法を参照することをお勧めします。
これが整ったら、コントローラー (ColdBox など) について考え、それを介してモデルをビューにリンクすることが可能になります。ただし、アプリケーションが必要とするテーブルに何らかの機能をもたらすコントローラーを慎重に検討し、選択してください (キャッシングが思い浮かぶ例です)。この新しいデザインと対話するには、おそらくビューも再考する必要がありますが、必要なのは、アルゴリズムが UI から切り離され、ビューの仕事が簡単になるシステムです。
現実的には、この問題に取り組む方法は反復です。私が説明した方法で簡単に解きほぐすことができるシステムを 1 つ見つけて、それを単体テストで取得し、人々と一緒に検証してから、次のシステムに進みます。退屈なプロセスではありますが、すべてを書き直そうとするよりもはるかに手間がかからないことは保証できます。これは、事前に非常に優れた自動検証セットを持っていない限り、災害を招きます。
繰り返しますが、この技術はあなたの問題を解決するものではありません。よりまとまりのあるオブジェクトに向けて継続的に反復します。
結合されたデータに関する限り、ORM ではトレードオフが行われ、モノリシック システムには確かに利点があります。別のアプローチは、DI を介して 1 つのステートフル エンティティに別のサービス オブジェクトへの参照を与え、それを介して取得できるようにすることです。これにより、単体テストの目的でモックを作成し、同様のサービス オブジェクトと対応するエンティティに置き換えて、他のコンテキストでの再利用を容易にすることができます。
ビジネス上の問題 (会計など) を解決するという点では、再利用は、ほぼ同じことを行う複数のシステムを作成してから、一般化する方法を見つけ出す緊急の特性です。私の経験では、再利用可能なコンポーネントになるビジネス上の問題を解決するために何かを書き始めることはめったにありません。
モジュールを調べることに時間を費やすことをお勧めします。モデルとの統合を維持しながら、コードを論理機能に分割するのに役立ちます。
ColdBox であるため、ドキュメントと例がたくさんあります...
幸いなことに、ここで直面している問題は固有のものではありません。
ここで問題となるのは、コードそのものや分解方法ではなく、ERP の設計と開発に取り掛かっていることを理解することです。
この組織の詳細を論理的な方法で管理する ERP を開発および成長させる最善の方法を知ることは、あなたが理解しようとしている、より深い問題だと思います。このフローからコーディングする方法の設計とアーキテクチャ自体は、必要なコア機能領域の理解から始まります。
幸いなことに、入手できる既存の ERP システムをいくつか調査して、それらがいくつかの問題にどのように取り組んだかを確認できます。いくつかの優れたオープン ソース ERP があります。このヒントを思いついたのは、私が監督した SAP Business One (大規模な SAP の課題を回避する中小規模の ERP) のフル サイクル インストールです。
あなたが探しているのは、あなたが直面しているのと同じ ERP アーキテクチャを他の人がどのように解決しているかを見ることです。少なくとも、モジュール化の間のトレードオフ、モジュール間の線引きの場所、およびその理由について理解することができます。
通常、ERP システムは、見積もりから生産 (必要な場合)、請求、出荷、および結果として生じる経理作業まで、すべてを処理します。
ERPS は、次の 2 つの主要な世界を処理します。
一部のビジネスはウィジェット ファクトリーであり、他のビジネスはサービス ビジネスです。すぐに使用できるフル機能の ERP には、「注文」の 1 つの連続したチェーン/ライフサイクルがあり、多くのステップで処理されます。
ERP がカバーできる手順の大まかなリストを読むと、自分に当てはまる手順がわかります。これらはおそらく、あなたが持っているか、アプリを分割する必要があるモジュールです。それぞれが異なるドキュメントであり、すべてがチェーン内の前のドキュメントに接続されている次のステップを想像してください。
システム インテグレーターの出番は、必要な手順を使用し、使用されていない手順をスキップすることです。これは、成長中のアプリに 1 つのことをもたらします。
堅実なデータ セキュリティ戦略を策定します。誰もが見るべきものだけを見ることができるように、快適であることを確認してください。それが整っていると仮定すると、アプリを主要なセクションに分割することをお勧めします。モジュールは私たちの友達です。ただし、それらを分割する順序は、何よりもあなたの行動に大きな影響を与える可能性があります.
複数のアプリ間で再利用できる一般的なセクション (レポートなど) と、アプリケーション自体に特化したセクションを確認してください。アプリケーション自体に関連付けられている機能は、すでにより緊密に結合されている可能性が高く、それを回避する必要がある場合があります。
ERP の場合、私は常にトランザクションの「コア」モジュールを好んでいました。これは、他のすべてのトランザクション プロバイダー (プロセスが定義されると請求がプロセスをプッシュします) と同じです。
Lotus Notes ERP を 90 年代から SAP ERP に変換したとき、Lotus Notes アプリは素晴らしく、すべてを適切に処理しました。モジュールとして統合されていない側で構築されたいくつかのミニアプリがあり、それがそれを取り除く主な理由でした.
今日の要件でアプリを書き直したとしたら、どのように変更したでしょうか? あなたが持っているものとの大きな違いがあるかどうかを確認してください。最初にオーバーホール/モジュール化が必要なものを決定するために、アプリに注意を向けさせる. ColdBox はモジュール化に最適です。プラグイン タイプのモジュールを使用している場合でも、適切に分離されたコードを使用している場合でも、失敗することはありません。これは、開発者の時間とお金の関数にすぎません。
単体テストをビルド/自動化する最初のモジュールは、プログラム的に最も複雑です。あなたがまともな開発者であれば、昨日の時点でエンドツーエンドの単体テストは必要ない可能性があります。最も複雑なものから始めて、アプリのコア部分に進み、夜更かしする可能性のある他の領域に広げます。
それが役に立ったことを願っています！よろしければ、あなたが何をしているかを共有してください。私が言及したことでさらに説明が必要な場合は、ここまたはツイッターで連絡してください:) @JasPanesar
MVC を取り除き、それを SOA アーキテクチャに置き換える必要があります。これにより、2 つの半分を結合するのはサービス リクエストだけになります。
したがって、サーバー側には DAO 層と FACADE 層があります。また、クライアント側は MVC にすることも、別の場所で使用したいアーキテクチャにすることもできます。個別のビジネスごとに個別のクライアントを持つこともできます。
サーバー側でも、プロジェクトを複数のサーバーに分割できます。つまり、すべてのビジネスに共通するものと、すべてのビジネス間で異なるものです。