계산과 부작용을 분리 할 때 "세계에 묻기"코드를 어디에 두어야합니까?

에 따르면 명령 쿼리 분리 원칙 뿐만 아니라, 데이터의 생각 과 의 Clojure와 DDD 하나, 계산과 결정에서 (세계 수정) 부작용을 분리해야 프리젠 테이션 그래서 두 부분을 이해하고 테스트하기 쉬울 것이다.

이 질문에 대한 답을 얻지 못합니다 : 우리는 상대적으로 경계를 어디에서 "세계에 묻기"해야합니까? 한편으로, 데이터베이스, 익스텐트 서비스 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