開発者は、JavaWebシステムをコントローラー/サービス/ Daoとその他のレベルに分割することを既に習慣にしています。この階層化されたアイデアの指導の下で、システムのパッケージ構造は一般に次のようになります。
もちろん、名前は異なりますが、beansとdaoはmodel、pojo、mapperと呼ばれることもありますが、意味は似ています。階層化に問題がない場合は、ビジネス、JMS、またはタスクパッケージが存在する可能性があります。
この種のパッケージ構造では、特定の機能（ユーザー管理機能など）のコードが3つのレイヤー（コントローラー、サービス、Dao）に分割され、それぞれのパッケージに入れられます。これは、レイヤー化の慣習に沿ったものです。そして、それはシンプルで明確に見えます。この構造が南と北で人気があり、それが永遠に続くことは不思議ではありません。
ただし、システムがどんどん大きくなり、ビジネスが複雑になるにつれて、システムにパッケージ構造を設定する方法とコードを整理する方法について新しいアイデアが生まれました。
考え方は簡単です。システム内のパッケージ構造を分割するときは、最初にビジネスをレイヤーに分割します。
比較として、元の方法は実際にはレイヤーとビジネスに分けられました。これに似ています：
上の図は、システムの1つのパッケージ構造です（com.company.systemは非表示です）。この図は、従来のパッケージ構造が「最初にレイヤーに分割され、次にビジネスに分割される」方法を明確に示しています。まず、コードのレベルに従ってクラスをコントローラーまたはサービス（もちろん、dao、beanなど）パッケージに分類し、次に、コントローラー/サービス/ dao / Beanなどのパッケージ内に、次にクラスが属するビジネス関数に従って、それらは異なるパッケージに割り当てられています。
実際、このシステムはより「デリケート」です。ほとんどのシステムは、それらが属する階層に従ってパッケージ構造を分割した後、クラスを同じレベルにまとめるだけでよく、ビジネスによってそれらを分割しなくなります。
「最初にレイヤーに分割し、次にビジネスに分割する」というパッケージ構造は、よく知っているはずです。それでは、「まずビジネスを分割してからレイヤーに分割する」というパッケージ構造はどのようなものでしょうか。上記のシステムを例として使用し、パッケージ構造を新しい方法で分割すると、次のようになります。
言い換えると、各クラスは、最初に、それが属するビジネス機能に応じて（auth、userなどの）異なるパッケージの下に配置され、次に、それが属するレベルに従ってコントローラー/サービス/ daoまたはその他のパッケージに分割されます。画像を使用して2つのパケット構造を分割するための基礎を説明する場合、おそらく次のようになります。
優先度レベルや優先度の高いビジネスに関係なく、焦点は複雑さを分割して管理する方法です。どちらの方法にも独自のメリットがあり、誰よりも優れているものはありません。したがって、「最初に事業を分割してから事業を分割する」ことの何が悪いのかについては話さず、「最初に事業を分割してから事業を分割する」のが好きな理由についてだけ話します。
当時、私たちはモジュールをリファクタリングしていました。これは計算モジュールです。これは非常に重要であり、頻繁に呼び出されます。再構築の前と後の計算結果は同じでなければならず、同時に非常に複雑です。広範なテストを行った後でも、関数が正しいことを保証するものではありません。したがって、新しいコードで非常に詳細なログを出力し、すべての呼び出しですべてのステップのすべての変数を追跡できるようにします。
明らかに、この戦略はオンラインログ量の急増につながります。オンラインにした後、このモジュールのログは15G /日に達しました。3日後、「ディスクの空き容量が10％未満」という警告を受け取りました。もちろん、そのような詳細なログのおかげで、オンラインにした後の最初の日に3つの機能上の問題を修正しました; 3日目に、パフォーマンスのボトルネックを分析して見つけました（平均250ミリ秒+呼び出しを35ミリ秒に最適化）左と右）。これらの問題の修正とパフォーマンスの最適化を完了した後、リファクタリングが目的を確実に達成するために別の日を観察しました。
最後に、5日目に、log4j2.xmlの2行の構成を変更して、ログの量を1G /日未満に減らしました。これらの2行の構成は次のようになります。
<!-- 原先下面这行配置的level为INFO -->
<Logger name="com.company.system.calculate" level="WARN" />
<!-- 原先没有下面这行配置 -->
<Logger name="com.company.system.calculate.web" level="INFO" />誰もがこれらの2行の構成の役割を一目で理解できると思います。このような単純な2行構成を使用してログの量を大幅に削減できる理由の1つは、パッケージ構造が「最初にビジネスに分割され、次にレイヤーに分割される」ためです。これが、このパッケージ構造を使用することで得られる最初の利点です。
もちろん、この利点は説得力のあるものではありません。ログ出力の調整は問題ではありません。しかし、システムをさらに再構築するにつれ、「最初にビジネスを分割し、次にレイヤーを分割する」ことには別の利点がありました。
先に述べたように、この計算モジュールは重要で、複雑で、ストレスを伴います。そのため、このモジュールを独立したサービスに分割することにしました。最初のリファクタリングの後、優れた機能、パフォーマンス、構造を備えた一連のコードがすでにあります。したがって、2回目のリファクタリング中に、別のコードセットを作成することは計画せず、コピーすることだけを計画しました。
このモジュールのコアコードは同じパッケージにあるため、このコピーは非常にシンプルでスムーズです。このパッケージを移動した後、残っているのは一般的なコードと構成のごく一部です。したがって、2番目のシステムの再構築は非常に簡単に完了しました。
これは、「ビジネスを最初に分割し、次にレイヤーを分割する」というパッケージ構造によってもたらされる2番目の利点です。この利点は説得力があるとは思われません。すべてのモジュールとコードを独立したサービスに分割できるように常に準備する必要があるわけではありません。
しかし、私はまだ「ビジネスを最初に分割し、次にレイヤーを分割する」というパッケージ構造を好みます。これは、製品、ビジネスの抽象化、モジュール化とサービスにより傾くシステム構造と設計のアイデアを意味します。この議論はまだ説得力がありませんが。
したがって、「最初の事業部門、次に階層」または「最初の階層部門、次に事業部門」のいずれであるかについて区別はありません。私たちがシステムの設計と開発で行うすべての選択とすべての決定は、同じことだけでなく、思考、比較、およびトレードオフの結果である必要があるだけです。
