序章
前回の記事では、単一のドメイン サービスに分割されたマイクロサービスのドメイン駆動設計について紹介しました。各ドメイン内には、ドメイン固有のコンピテンシーがあります。このように、単一のサービスのロジックは比較的純粋で単一であり、最終的にビジネス モジュール レイヤーはさまざまな分野の機能の統合を完了できます。これが最も理想的な結果です。ただし、多くの企業の実際のプロジェクト レベルの開発では、さらに多くの問題が発生します。
- ビジネス機能の結合は深刻で、ドメイン間の通信が頻繁に行われる.ビジネスモジュール層のいくつかの微妙なロジックが処理できず、ドメイン層で他のドメイン機能を呼び出す必要があることがよくある.
例：オーダー業務を行う場合、オーダー内のユーザーサービスに直接アクセスするためにユーザー情報にアクセスする必要があり、同時にユーザー情報を利用する際にオーダー関連情報にもアクセスすることになります。
- ドメイン層のロジックは頻繁に変更されます: 多くの企業は、初期段階でビジネス機能を満たすことができますが、何度か繰り返した後、ロジックの書き換えが必要であることが判明し、場合によってはオンライン バグに直接つながることさえあります。レビューでも当時の機能に合わせてコードが書かれており、問題はなかったとのこと。
例: 手続き型のビジネスを行う場合、多くの手続き型ロジックがドメイン層に直接記述されるため、ドメイン層によって提供される機能が煩雑になる. その後の反復的なプロセス変更がある場合、コード全体を変更して、最終的に見つける必要があります.このアビリティは他のサービスからも参照されており、最終的には書き換えることしかできないため、見つからないとビジネスにバグが発生します
上記の問題は、私たちの仕事のプロジェクトにのみよく見られるものであり、このような状況はほとんどの企業で確実に発生します.私の「プロの仕事の方法論」を使用してプロジェクトを実行する限り、必ず見つけることができます.
ロジックのプログラミング
問題はすでに存在するので、ドメイン駆動設計によってもたらされる利点を維持し、結果を拡大するには、上記の問題をどのように回避する必要がありますか? 私の要約分析によると、それは私たちのプログラミングの習慣の問題だと思います.私が提唱したコア理論の1つは、プログラミングの習慣をターゲットロジックプログラミングに変更することです. 以下では、ロジックをプログラミングする理由と方法を順を追って説明します。
ロジックをプログラミングする理由
その理由は実は非常に直接的で単純、つまり抽象的なものです。実際、抽象的思考は、主語と目的語の特徴と修飾語を大部分無視し、述語と主語と目的語という単純な実体を保持しています。このように、より論理的な記述に近づいています。説明など: 100 万の金持ちが杭州の 4S ストアで非常に豪華で美しいメルセデスベンツを購入しました. 抽象化は、1 人が商品を購入したということです. コードフィールドを全体のロジックに抽象化できれば、製品を購入するという行為全体が普遍的になり、どのような人がどのような製品を購入するかは、すべてビジネスモジュールのシナリオによって与えられる内容になります。このように奉仕する能力は、単一で純粋です。
ロジックのプログラミング方法
例: 100 万ドルの金持ちが、杭州の 4S ストアで非常に豪華で美しいメルセデスベンツを購入しました。
ソフトウェアの実装: 多くのソフトウェア開発者やデザイナーは、最初に購入者を億万長者と定義し、車はメルセデスベンツと直接書かれており、購入場所は 4S ストアです。
事後反復: 他の場所で車を購入したい別のカテゴリーの人々を完成させる必要がある場合、この関数は基本的に書き直す必要があります。
上記の例から、例を挙げただけです. 例は理解の便宜のためであり、人や車は私たちが理解しやすいオブジェクトです. このプロジェクトでは、オブジェクトの設計が非常に重要です (オブジェクトの分解設計については、他のブログ投稿で紹介しました)。オブジェクトが設計された後、論理的な抽象化を実行し、表、補数、属性などを削除します。最後に残っている主な主語-動詞-目的語は、私たちが望む記述の論理です。ドメイン層でこの機能を完了するだけで済みます。
エピローグ
この記事の内容は比較的単純ですが、全体として、抽象化能力を向上させ、この能力をプログラミングに適用することは、論理プログラミングを目的としています。連想機能オブジェクト設計、ドメイン駆動設計については、他のブログ記事で取り上げています。個人的には、ロジック プログラミングは、複雑な問題に直面したときに集中力を高め、コア ロジックのみに集中する能力を向上させるものでもあると思います。
さらに、次のように、あなたにインスピレーションを与えることを期待して、例の肯定的な解決策が添付されています。
例: 100 万ドルの金持ちが、杭州の 4S ストアで非常に豪華で美しいメルセデスベンツを購入しました。
抽象的な分析:
オブジェクト: 人、車
属性:
人間属性：億万長者
商品属性：BMW、車、高級品
イベント プロパティ:
場所: 杭州、4S ストア
- コア ロジック: 人々が商品を購入した
- 属性コンテンツの割り当て
コード：
- 注文センター - 商品を購入する人々
- 商品センター - 商品の作成と定義
- ユーザー センター - バイヤーの作成
ビジネス層は、これら 3 つのフィールドの機能を呼び出すことによって、最終的な機能を完了します。後の段階でのその他の購入トランザクションについては、製品と製品に関連する情報の定義、およびユーザーのメンテナンスのみが必要です。マイクロサービスのそれぞれの反復的な進歩を実現できます。
理解するのは簡単です。例は比較的単純ですが、ロジック プログラミングの方法は次のようになります。コアの方法論です。
- 完全記述機能
- 主語、述語、および目的語を保持し、表の補足を削除します
- 表の補足作成を個別に完了する
- 完全な主語-動詞-目的語の論理プログラミング