Episode 218: DDD and CQRS on Service Fabric with MediaValet

Play Episode 218: DDD and CQRS on Service Fabric with MediaValet

Description

In this episode Haishi Bai is joined by Jean Lozano, Sergiy Chernets and Stanley Chen from MediaValet. Jean, CTO of MediaValet, shares MediaValet's journey to Azure, and reviews how MediaValet's system evolves with the platform. Then, Sergiy reviews several key concepts and principles in Domain Driven Design (DDD), and how MediaValet maps these concepts to Microsoft Service Fabric Actor programming model. The team also discusses how they implement the Command and Query Responsibility Segregation (CQRS) pattern and Event Sourcing on Service Fabric. Finally, Stanley walks through some conceptual codes showing how to implement a Process Manager using reminders that allow actors to communicate in an asynchronous fashion.

As we see more and more customers using Azure for their large-scale, mission-critical workloads in production, we try to bring more patterns & best practices episodes into the Cloud Cover show to help you to get the most out of Azure. Please let us know if you want to see more of such episodes!

Links from the show:

  • [01:32] - Jean Lozano: MediaValet's journey to the cloud
  • [14:28] - Sergiy Chernets: DDD principles and concepts 
  • [24:03] - Sergiy Chernets: Mapping DDD concepts to Service Fabric actors
  • [38:16] - Stanley Chen: Conceptual code demo
  • MediaValet

Like Cloud Cover on Facebook!




Embed

Download

The Discussion

  • User profile image
    anthonychu

    Great introduction to DDD/CQRS/ES and how the Service Fabric programming models map almost directly to these concepts. Very impressive. Thanks!

  • User profile image
    schernets

    @anthonychu:Thank you, Anthony. Glad it is helpful. 

  • User profile image
    aljj

    Very interesting how you put all the pieces together DDD, Microservices, Actor Model and SF. Really beautiful.

    About the underlying framework, how many man days it took to build?

  • User profile image
    schernets

    @aljj, Thank you. It is hard to quantify. We approached this with an established DDD experience in the team. It took less than 5 months for a team of 6 engineers with various levels of experience to create a core abstraction. But again, it is really subjective.  

  • User profile image
    patheyacine

    It is very interesting to see a real life  implementation of DDD and Azure service Fabric. Good job

  • User profile image
    schernets

    @patheyacine:Thank you. Appreciate the feedback. 

  • User profile image
    sen3

    Thank you for the great intro. How is the read side of the actor model? How does the query flows? 

  • User profile image
    schernets

    @sen3: Thank you. Could you be more specific in your question? What exactly do you mean in "How is the read side of the actor model? How does the query flows? "

  • User profile image
    sen3

    I meant to ask how do you do the reading part? for example getting the Document by Id? How do you get the materialized data? Do you have another set of services doing the read? Thanks.

  • User profile image
    schernets

    @sen3:Yes. By definition, the system is message driven. The writes are events, the reads are flat, request-tailored, denormalized, materialized views . They could be consumed by a separate set of services. The idea is not to mix them. The writes are usually command driven.

  • User profile image
    Gaurav Dhamija

    Great information! Can you please share more information about Process Manager implementation. Did you have a scenario where you had to co-ordinate between multiple actors? How did you handle rollbacks?

  • User profile image
    schernets

    @Gaurav Dhamija: The Process Manager design pattern is aimed to solve the problem of exactly what it says - How to manage the process. In other words, it is a solution for the workflow like scenarios - how to coordinate a multi step process. If one has a multi step asynchronous long running process - process manager could be a solution. Every step in the process could be performed by a specific actor. Process Manager does not usually coordinates anything between the actors. Actors should be unaware that they are part of anythings. Actors may do some work, delegate it to another actor and/or send a message. Process Manager is also an Actor. Everything is an Actor. Actors must not be heavy on compute in order to avoid blocking

    In case of a "rollback" situation, every step of the process should have a compensating step. It is a part of the process. Since everything is message driven and distributed we should design for failures. 

  • User profile image
    Erkan

    Thanks for video. You said you apply event sourcing with sequence. How do you apply this on Service Fabric.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.