秘密のソースをコード化する

各アプリケーションには秘密のソース、つまり存在する理由があります。秘密のソースをコード化することは、保守性が高く成功したアプリケーションを書くために不可欠です。

ちょっと待ってください。コード化とは何でしょうか？ご辛抱ください。そこに到達します。

まず仮説を立ててみましょう：

あなたはシニアソフトウェアエンジニアに昇進したばかりです（おめでとうございます！）。CEOの最初のタスクは、会社向けの新しい製品を作成することです。それはゼロから構築する会計アプリケーションです。経営陣は、カスタム会計ソリューションを持つことで競争相手に対して優位性を得られると考えています。

数ヶ月が経ちました。ほとんどの横断的関心事が開発されました（やったね！）。チームはアプリケーションの素晴らしい部分、つまりビジネスドメイン（秘密のソース）に焦点を当てています。ここが秘密のソースをコード化し始める場所です。

コード化とは、ビジネスドメイン内の本質的な概念に構造を付けることです。

会計では、株価収益率（P/E Ratio）は企業の収益の測定値です。高いP/E比率は将来の高い収益成長を示唆しています。P/E比率は、1株あたりの市場価値（株価）を1株あたりの利益（利益 - 配当金 / 発行済み株式数）で割ることで計算されます。

シンプルで、私は主張しますが、素朴な実装：

public class Metric
{
    public string Name { get; set; }
    public decimal Value {get; set}
    public int Order {get; set;}
}
public class AccountingSummary
{
    public Metric[] GetMetrics(decimal price, decimal earnings)
    {
        var priceEarningsRatio = price/earnings;
        
        var priceEarningsRatioMetric = new Metric 
        {
            Name = "P/E Ratio",
            Value = priceEarningsRatio,
            Order = 0
        }
        return new [] {priceEarningsRatioMetric};
    }
}

これが1つの場所でのみ使用される場合、これは問題ありません。P/E比率を他の領域で使用する場合はどうでしょうか？

ここのような PriceEarnings.cs

var priceEarningsRatio = price/earnings;

そして AccountSummary.cs ここに

var priceEarningsRatio = price/earnings;

そしてここの StockSummary.cs に

var priceEarningsRatio = price/earnings;

P/E比率はこのアプリケーションの中核ですが、その実装方法、つまり様々な場所にハードコードされている方法は、P/E比率の重要性をコードの海に埋もれさせています。それは単なる森の中の別の木です。

また、ある場所で比率を変更しても他の場所では変更しないというリスクも開いています。これは下流の計算に支障をきたす可能性があります。このタイプのエラーは見つけるのが非常に難しいことで知られています。

多くの場合、テスターはある領域で機能する場合、すべての領域で正しいと仮定します。アプリケーション全体でP/E比率を生成するために同じコードを使用しないのはなぜでしょうか？これはオブジェクト指向プログラミングの要点ではないでしょうか？

このようなエラーが本番環境に入り、経営幹部の訪問まで発見されないシナリオを想像できます。経営幹部は、SECのP/E比率計算が会社が提出したものと異なる理由を知りたいと要求しています。それは素晴らしい場所ではありません。

P/E比率の実装を再検討して、最初の試みをどのように改善できるかを見てみましょう。

会計システムではフォーミュラが存在するため、インターフェースを追加してフォーミュラの周りに構造を配置しましょう：

public interface IFormula
{
    decimal Calculate<T>(T model);
}

各フォーミュラはこのインターフェースで実装され、一貫性と予測可能性を提供します。

インターフェースを実装した後の改善されたP/E比率は次のとおりです：

PriceEarningsModelを追加して、必要なデータをCalculateメソッドに渡しました。

public class PriceEarningsModel
{
    public decimal Price {get; set;}
    public decimal Earnings {get; set;}
}

PriceEarningsModelを使用して、P/E比率のIFormulaインターフェースの実装を作成しました。

public class PriceEarningsRatioFormula : IFormula
{
    public decimal Calculate<PriceEarningsModel>(PriceEarningsModel model)
    {
        return model.Price / model.Earnings;
    }
}

P/E比率をコード化しました。これはアプリケーション内のファーストクラスの概念です。どこでも使用できます。テスト可能で、変更はアプリケーション全体に影響します。

念のため、ここが私たちが始めた実装です：

public class Metric
{
    public string Name { get; set; }
    public decimal Value {get; set}
    public int Order {get; set;}
}
public class AccountingSummary
{
    public Metric[] GetMetrics(decimal price, decimal earnings)
    {
        var priceEarningsRatio = price/earnings;
        
        var priceEarningsRatioMetric = new Metric 
        {
            Name = "P/E Ratio",
            Value = priceEarningsRatio,
            Order = 0
        }
        return new [] {priceEarningsRatioMetric};
    }
}

シンプルで仕事を成し遂げます。問題は、会計アプリケーションの中核概念であるP/E比率が目立たないことです。アプリケーションやビジネスドメインに精通していないエンジニアは、その重要性を理解しません。

改善された実装は新しいP/E比率クラスを使用します。PriceEarningsRatioFormulaクラスをAccountSummaryクラスに注入します。

ハードコードされたP/E比率を新しいPriceEarningsRatioFormulaクラスに置き換えます。

public class AccountingSummary
{
    private PriceEarningsRatioFormula _peRatio;
    
    public AccountingSummary(PriceEarningsRatioFormula peRatio)
    {
        _peRatio = peRatio;
    }
    
    public Metric[] GetMetrics(decimal price, decimal earnings)
    {
        var priceEarningsRatio = _peRatio.Calculate(new PriceEarningsModel 
        { 
            Price = price, 
            Earnings = earnings
        });
        
        var priceEarningsRatioMetric = new Metric 
        {
            Name = "P/E Ratio",
            Value = priceEarningsRatio,
            Order = 0
        }
        return new [] {priceEarningsRatioMetric};
    }
}

PriceEarningsRationFormulaは前の実装よりも少し多くの作業があると主張する人もいるでしょう。そして私は同意します。少し多くの儀式がありますが、利点は小さなコードと儀式の増加の価値があります。

まず、アプリケーション全体のP/E比率を変更する機能を獲得します。欠陥が発生した場合、デバッグする単一の実装もあります。

最後に、アプリケーション内のPriceEarningsRatioFormulaの概念をコード化しました。新しいエンジニアがチームに参加すると、フォーミュラがアプリケーションとビジネスドメインに不可欠であることを知ります。

マイクロサービスとアセンブリなど、ドメインをコード化（カプセル化）する他の方法があります。各アプローチには長所と短所があり、あなたとあなたのチームはアプリケーションに最適なものを決定する必要があります。

クラスとインターフェースにキードメインの概念を組み込むことで、再利用可能なコンポーネントと概念的な境界が作成されます。アプリケーションを推論しやすくし、欠陥を減らし、新しいエンジニアのオンボーディングの障壁を低くします。