액터는 매우 가벼운 동시성  엔터티들이다.  event-driven receive loop를 이용하여 비동기적 메시지를 처리한다.

동시 처리성을 높이려면 Dispatcher 를이용 ,분산처리 확장은 Cluster가 활용될수 있으며 로컬용으로 작성된 개발방법이 크게 달라지지 않습니다.

AKKA는 액터를 전반적으로 활용하기때문에 액터패턴에 대한 컨셉을 먼저 살펴보겠습니다.

소프트웨어 설계에 있어서 경험만큼 확실한 것은 없다. 그러나 문제는 모든 사람들이 충분한 경험을 갖고 있지는 않다는 사실이다.

그렇다면 충분한 경험을 갖지 못한 사람들이 많은 경험을 가진 전문가 못지않게 소프트웨어 설계를 잘 할 수 있도록 만들어 줄수 있는 방법은 무엇일까?

소프트웨어 설계 방법론과 지침을 통한 공유

=> 접근의 한계가 있음, 방법론이나 지침은 일반화된 것이어서 구체적인 문제에 적용하기 위해서는 또다른 지식이필요

사례를 통한 공유

=> 사례는 너무 구체적이고 특정 문제의 가정에 의존

위 두가지 모두 한계점이있으며

일반적이지도, 또 너무 구체적이지도 않은 형태의 소프트웨어 설계를 위한 지침을 고민하면서

생긴게 디자인 패턴이다. ( Design Patterns : Elements of Reusable Object-Oriented Software)

- 여기에 포함되는 패턴이 GoF(이분야의 4인방)  디자인 패턴이다.

Erich Gamma외 3명은 다음과 같은 절차로 디자인 패턴을 정립화 하였다.  ( 새로운 디자인 패턴도 아래와같은 과정으로 생겨난다.)

1. 여러가지 설계 사례를 분류
2. 각 유형별로 가장 적합한 설계를 일반화 시켜 패턴으로 정립
3. 이중 다시 쉽게 재사용가능한 객체 지향 개념에 따른 설계만 패턴으로 지정
   
   

디자인 패턴이 휼륭한 원서임에도 불구하고 다음과 같은 약점이 있음

1. 해결하고자하는 문제의 유형이 적고
2. 디자인 패턴이 설계되기까지 어떤 측면에서 고민이 이루어졌는지에대한 유도과정이 확실치 않으며
3. 디자인 패턴에서 제시하는 설계가 일반적인 개발자들의 설계와 비교할때 어떠한 장단점을 가지는지 언급이 안됨

여기까지 Gof 디자인 패턴 이렇게 활용한다 -C++로 배우는 패턴의 이해와활용에서 발췌

디자인 패턴은 이러한거다란 정도 알고 넘어갑시다.

    public class DeepThought
    {
        private int state;

        public int State
        {
            get
            {
                lock (this)
                {
                    Thread.Sleep(3000); //나의 상태에대한 깊은 생각에 빠짐..나는누군가? 여긴어딘가?
                    return state;
                }                
            }

            set
            {
                lock (this)
                {
                    //깊은 생각에 빠질땐 누구도 건들지 말기를 바람,그대가 최고우선순위 스레드라할지라도
                    state = value;
                }                
            }
        }        
    }
var dt = new DeepThought()

Thread.new { console.log( dt.State ) }
Thread.new { dt.State=1 }

public class MyActor: ReceiveActor
{
  //Actor모델 에서는 안전한 동시성처리를 위해 어떠한 프로퍼티(속성)도 공유가 필요없음으로, 속성 접근제한에 priave만으로 충분합니다.
  private readonly ILoggingAdapter log = Context.GetLogger();
  private int state =0;

  public MyActor()
  {
    Receive<string>(message => {
      log.Info("Received String message: {0}", message);
      Sender.Tell(state );
    });
    Receive<SomeMessage>(message => {...});
  }
}

//코드 변경 최소로 옵션만으로 로컬,원격,클러스터등러등의 작동 선택 전략이 가능하다.
var remoteActor = system.ActorSelection("akka.tcp://MyServer@127.0.0.1:8001/user/someActor"); 

// 질의를 하던지?(Ask), 단지 말만한다던지?(Tell), 결과를 기다리던지(Result)? 
// 객체 접근 기반이아닌 메시지 전송기반의 인터페이스를 사용하는 조금더 추상화된 모델이다.
// Tell의 의미를 상세히 분석하면, 내가 한말에 결과값이 필요없으니 처리만해달라란 의미이며 
// 네트워크상의 의미로 수행결과가 있어도 어떠한 값을 리턴한다고 해도, 결과메시지 자체가 발송되지 않습니다.
var state = remoteActor.Ask("Hello").Result; 

액터의 특징을 살펴 보고자 반대편에 있는 OOP를 이용한 스레드 직접 제어의 단점을 예를 들었지만

액터 시스템도 Dispatcher 란 튜닝가능 객체가 스레드 풀을 이용을 하며, OOP로 작성된 추상화 객체입니다.

도메인 메시지 처리에 있어 스레드를 이용하는 OOP적 설계방식이 단순성을 유지하고 확장에 유연한 개발능력을 가지고 있는가?

스스로 질문을 던저볼수 있으며, 메시징 처리에 있어 동시성 처리를 포함한 다음 3가지 주제는  액터나 아카와 상관없는

공통주제로 , 액터를 연마하기전 추천 선행 자료입니다. 

• Future and Promise
• Routing strategy
• MessageDeliveryReliability