Доменные службы и ограниченный контекст с использованием Akka — часть 2

Еще одним важным артефактом доменной модели являются доменные сервисы. Доменная служба не обязательно ориентирована на какую-либо конкретную сущность и в основном сосредоточена вокруг глаголов системы. Он моделирует некоторые действия или варианты использования с участием нескольких объектов и обычно реализуется как абстракция без сохранения состояния.

Используя Akka, вы моделируете сервис как еще одного актера. Доменные сервисы — это грубые абстракции уровня и те, которые получают запросы от клиентов. Он может вызывать другие службы или использовать любые другие права для выполнения работы, которую он должен делать. Неудивительно, что занятый сервис получает запросы от множества потребителей. Он не только должен быть стабильным, но и должен обеспечивать, чтобы все его другие службы, с которыми он сотрудничал, также оставались в живых при обслуживании запросов.

Одним из сервисов, с которыми он взаимодействует, является репозиторий доменов, о котором я говорил в предыдущем посте.

Разрабатывая доменную службу с использованием акторов Akka, вы можете гарантировать, что служба сможет сделать свои совместные службы отказоустойчивыми благодаря декларативному или минимальному программированию. Akka runtime предлагает все механизмы, которые упрощают внедрение отказоустойчивых сервисов.

Рассмотрим следующую службу домена для управления учетными записями, продолжая наш предыдущий пример из последнего поста.

trait AccountServer extends Actor {
  // handle crash
  faultHandler = Some(OneForOneStrategy(5, 5000))
  trapExit = List(classOf[Exception])
  
  // abstract val : the Repository Service
  val storage: AccountRepository

  // message handler
  def receive = {
    case Open(no, name) => 
      storage ! New(Account(no, name, Calendar.getInstance.getTime, None, 100))
    case msg @ Balance(_) => storage forward msg
    case msg @ Post(_, _) => storage forward msg
    case msg @ OpenM(as) => storage forward msg
  }
  
  // shutdown hook
  override def shutdown = { 
    unlink(storage)
    storage.stop
  }
}

Обработчик сообщений является стандартным, который перенаправляет клиентские запросы в хранилище. Обратите внимание на использование абстрактного хранилища val: AccountRepository, которое помогает вам отложить фиксацию для конкретного класса реализации до создания экземпляра объекта службы.

AccountServer играет роль супервизора для субъекта хранилища. Первые 2 строки кода определяют стратегию надзора. OneForOneStrategy говорит, что
только компонент, который потерпел крах, будет перезапущен. Вы можете сделать это AllForOne также, когда контролирующий актер перезапустит
всех актеров , которых он контролирует, если один из них потерпит крах. trapExit определяет список исключений в связанном действующем субъекте, для которого контролирующий субъект будет выполнять действие.

AccountServer является действующим лицом для хранилища. Когда он выключен, он должен быть отключен от связанных актеров. Это мы делаем в хуке выключения AccountServer.

Но как нам связать актера репозитория с нашим актором доменной службы? Обратите внимание, что AccountServer еще не является конкретным объектом. Нам нужно создать конкретную реализацию AccountRepository и назначить ее для хранения в AccountServer. И свяжите два во время этого экземпляра.

Мы определяем другую черту, которая разрешает абстрактный val, который мы определили в AccountServer, и предоставляет конкретный экземпляр AccountRepository. spawnLink не только запускает экземпляр реализации репозитория на основе Redis, но также связывает субъект репозитория с AccountServer.

trait RedisAccountRepositoryFactory { this: Actor =>
  val storage: AccountRepository = spawnLink(classOf[RedisAccountRepository]) 
}


Now we have all the components needed to instantiate a fault tolerant domain service object.

object AccountService extends 
  AccountServer with 
  RedisAccountRepositoryFactory {

  // start the service
  override def start: Actor = {
    super.start
    RemoteNode.start("localhost", 9999)
    RemoteNode.register("account:service", this)
    this
  }
}

Посмотрите на метод запуска, который запускает службу на удаленном узле. Мы запускаем удаленный узел, а затем регистрируем текущий сервис под идентификатором
«account: service» . Любой клиент, которому необходимо использовать службу, может получить субъект службы, указав этот идентификатор .. как показано в следующем фрагменте.

class AccountClient(val client: String) { 
  import Actor.Sender.Self
  val service = RemoteClient.actorFor("account:service", "localhost", 9999)

  def open(no: String, name: String) = service ! Open(no, name)
  def balance(no: String): Option[Int] = 
    (service !! Balance(no)).getOrElse(
      throw new Exception("cannot get balance from server"))
  def post(no: String, amount: Int) = service ! Post(no, amount)
  def openMulti(as: List[(String, String)]) = service !!! OpenMulti(as)
}

Сервисы, определенные с использованием Akka, могут быть запущены на удаленных узлах без особых технических проблем. Akka runtime предлагает API для этого. Тем не менее, Акка никогда не пытается скрыть от вас парадигмы распределения. Вы должны знать о своих требованиях к дистрибуции и иерархии процессов и контроля. Akka помогает вам определить их на уровне приложения, выполняя тяжелую работу в рамках своей базовой реализации. Этот принцип основан на философии Эрланга и резко контрастирует с RPC-способом определения API. Наряду с преимуществами вычислений на основе сообщений, которые разъединяют отправителя и получателя, Akka также позволяет обрабатывать состояния с помощью встроенного STM и подключаемого механизма хранения.

Когда вы моделируете сложный домен, вам нужно иметь дело с несколькими контекстами, которые Эрик называет
Ограниченный контекст с. В конкретном контексте у вас есть связная модель с набором поведения и абстракций домена. Интерпретации одних и тех же абстракций могут измениться, когда вы перейдете в другой контекст в одном приложении. Как разработчик модели домена, вы должны очень тщательно определить границы контекста, используя карты контекста, и реализовать соответствующие карты перевода между несколькими контекстами.

Обмен сообщениями — отличный способ реализовать перевод между контекстами. Вы обрабатываете сообщения в контексте, используя доменные службы, как описано выше, и в конце пересылаете одно и то же сообщение или переведенное в другие контексты приложения. Это может быть в форме push или вы можете также реализовать модель публикации / подписки между связанными контекстами. В последнем случае вы используете
Интеграция Akka-Camel , позволяющая актерам отправлять или получать сообщения через конечные точки Camel. В любом случае Akka предоставляет вам множество вариантов реализации слабо связанных контекстов домена, которые образуют компоненты модели вашего домена.