Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

A Functional approach to reactive microservice architecture

59 views

Published on

A Functional approach to reactive microservice architecture by Patrick di Loreto & José Escanciano

In this presentation we will talk about our approach to build complex and distributed applications following DDD and Reactive principles.

You will learn on how we approached this problem from a pure functional way using our opensource framework (reactive-platform), how Scala helped us through its advanced type system and DSL capabilities to combine underlying technologies such as Kafka, Cassandra and Akka to implement an actor distributed system based on CQRS/ES and NoSQL.

Published in: Technology
  • Be the first to comment

A Functional approach to reactive microservice architecture

  1. 1. Patrick Di Loreto Jose Luis Escanciano J on the Beach Malaga – 24/05/2018 https://github.com/patricknoir/reactive-platform
  2. 2. Patrick Di Loreto CTO Jose Luis Escanciano Chief Architect
  3. 3. Response in a timely manner Responsive under failure scenariosResponsive under load Enabler for responsiveness
  4. 4. Monolithic Microservices
  5. 5. Divide Conquer
  6. 6. § When implementing a system, we translate the reality into software that resemble the original business processes as much as possible. § Domain is an area of interest for the business. § Model is a set of abstractions and behaviors that reflect the real world. § Domain-Model is a blueprint of the entities and their relationships in a given domain, together with the following important details: § Entities that belong to the domain. § Interactions between the entities. § Ubiquitous language / Vocabulary of the domain. § Assumptions and constraints relevant to the domain.
  7. 7. Bookings: Hotel Room Guest Registrations: Booking Amenity Employee Finance:
  8. 8. § Value Object: Immutable item defined uniquely by the values of its attributes. If an attribute changes, we’d be speaking of a different value object. § Entity: Item representing a subject in the reality which state is managed across his lifetime by its identity. Despite a change on its attributes, the entity is always identified by the same id. § Aggregate: Unit of consistency in your model, which inherently has a root aggregate – entity used to refer to the aggregate itself. § Service: Describes the behavior and constraints within the domain – define the use cases in the business logic.
  9. 9. § Bounded Context refers to a specific domain model, which is part of the whole domain. § Bounded contexts are intended to be self-contained (standalone module). § Which doesn’t mean they’re isolated, actually, bounded contexts quite often interact between each other in the whole domain, but it’s key to: § Keep them as loosely coupled as possible. § Reduce the interactions between them to the minimum. § Ensure communication between them are decoupled in space and time.
  10. 10. Bounded Context Commands Requests Events Events Responses MessageBus Bounded Context Commands Requests Events Events Responses Gateway Gateway Protocols Protocols Dispatch Messages Dispatch Messages
  11. 11. § Has a name § Is a function from In to Out § Service[-In, +Out](name: String, f: In => Out)
  12. 12. § Sometime services have to handle a state, so in order to elaborate a computation: they need to know the current state and they will also produce an output state. type StatefulService[S, Input, Output] = Service[(S, Input), (S, Output)] class Service[In, Out](name: String, f: In => Out) type In = (S, Input) type Out = (S, Output)
  13. 13. type In = (S, I) type Out = (S, O) class Service[In, Out](name: String, f: In => Out) f: (S, I) => (S, O) f: I => S => (S, O) // Currying: I => (S => (S,O)) f: I => State[S, O] // S => (S,O) = State[S,O] class StatefulService[S, I, O](name: String, f: I => State[S, O])
  14. 14. class Service[In, Out](name: String, f: In => Out) type ReactiveService[I, O] = Service[I, Future[O]] val f: I => Future[O] type ReactiveStatefulService[S, I, E] = StatefulService[I, Future[State[S, E]]] val f: I => Future[State[S, E]] O = State[S, E]
  15. 15. type Cmd[S] = StatefulService[S, Command, Event] val f: Command => State[S, Event] // f: (S,Command) => (S,Event) type Evt[S] = StatefulService[S, Event, Event] val f: Event => State[S, Event] // f: (S,Event) => (S,Event) type Ask[S] = StatefulService[S, Request, Response] val f: Request => State[S, Response] // f: (S,Request) => (_,Response)
  16. 16. § A microservice is a component developed to serve a specific functionaly in an effectively manner. Is a set of services (as we defined) that will deal on a specific problem. § CQRS: § Command § Query § Responsibility § Segregation § Encourage Separation of concerns between write and read models. § This separation can be extended into the microservices level where we will have: § Processors – which will manage the write model (deal with Commands) § Views – which will manage the read model (deal with Queries)
  17. 17. val modifiers: Set[StatefulService[S, Command, Event]] val reactors: Set[StatefulService[S, Event, Event]] trait Processor[S] { type RootAggregate = S }
  18. 18. val queries: Set[StatefulService[S, Request, Response]] val reactors: Set[StatefulService[S, Event, Event]] trait View[S] { type RootAggregate = S }
  19. 19. case class BoundedContext ( name: String, version:Version, processors: Set[Processor[_]], views: Set[View[_]] … )
  20. 20. WE’RE HIRING!

×