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.

1. Patrick Di Loreto
Jose Luis Escanciano
J on the Beach
Malaga – 24/05/2018
https://github.com/patricknoir/reactive-platform

3. Patrick Di Loreto
CTO
Jose Luis Escanciano
Chief Architect

4. Response in a
timely manner
Responsive under
failure scenariosResponsive
under load
Enabler for
responsiveness

5. Monolithic Microservices

6. Divide
Conquer

7. § 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.

8. Bookings:
Hotel
Room
Guest
Registrations: Booking
Amenity
Employee
Finance:

9. § 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.

10. § 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.

11. Bounded
Context
Commands
Requests
Events
Events
Responses
MessageBus
Bounded
Context
Commands
Requests
Events
Events
Responses
Gateway
Gateway
Protocols
Protocols
Dispatch Messages
Dispatch Messages

14. § Has a name
§ Is a function from In to Out
§ Service[-In, +Out](name: String, f: In => Out)

15. § 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)

16. 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])

17. 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]

18. 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)

19. § 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)

20. val modifiers: Set[StatefulService[S, Command, Event]]
val reactors: Set[StatefulService[S, Event, Event]]
trait Processor[S] {
type RootAggregate = S
}

21. val queries: Set[StatefulService[S, Request, Response]]
val reactors: Set[StatefulService[S, Event, Event]]
trait View[S] {
type RootAggregate = S
}

22. case class BoundedContext (
name: String,
version:Version,
processors: Set[Processor[_]],
views: Set[View[_]]
…
)

25. WE’RE HIRING!