計算と副作用を分離するとき、「世界に尋ねる」コードをどこに置くのですか？

よるとコマンドクエリ分離原則と同様に、データにおける思考とのClojureとDDD 1は、計算や意思決定から（世界の変更）の副作用を分ける必要があるプレゼンテーションので、両方の部分を理解し、テストするために容易になるという。

これは未回答の質問を残します。境界に対して相対的に、「世界に尋ねる」ことをどこに置くべきでしょうか？一方では、外部システム（データベース、エクステンションサービスのAPIなど）からのデータの要求は参照透過的ではないため、純粋な計算コードや意思決定コードと一緒に置かれるべきではありません。一方で、どのデータを要求する必要があるかが事前にわからない場合があるため、計算部分から切り離して引数として渡すことは問題があるか、おそらく不可能です。

一方で、どのデータを要求する必要があるかが事前にわからない場合があるため、計算部分から切り離して引数として渡すことは問題があるか、おそらく不可能です。

これは、コメントに記載されているように、データを取得する機能（たとえば、ファーストクラスの関数、インターフェイスを実装するオブジェクトなど）を渡すことで、副作用を分離するための便利なメカニズムを提供するインスタンスです。

本体が純粋な高次関数の純度は固定されていません：http : //books.google.com/books?id=Yb8azEfnDYgC & pg=PA143#v=onepage &q& f=false

私はこれについて書いて、このタイプの関数を潜在的に純粋な関数と呼んでいます：http : //adamjonrichardson.com/2014/01/13/potentially-pure-functions/

純粋な可能性のある関数とフォールスルー関数（分岐構造がなく、可能な限り機能しない）を組み合わせる場合、組み合わせを分離セットと呼び、副作用を非常に効果的に分離して、非常にテスト可能なコードを作成できます： http：// adamjonrichardson.com/2014/01/15/isolating-side-effects-using-isolation-sets/

結果をクラスに格納します。これは最初は少し奇妙に見えますが、コードはより単純になります。たとえば、呼び出し元に一時変数はありません。

class database_querier
    feature -- queries
        was_previous_query_ok : boolean is
            do
                Result = …
            end

        previous_query_result : string is 
            requires
                was_previous_query_ok
            do
                Result = query_result
            end

    feature -- commands
        query_db (…) is
            do
                …
                query_result = bla
            end

    feature {none} --data
        query_result : string