1 / 24

DDD in a Clojure Event-Driven Application

DDD in a Clojure Event-Driven Application. Gilles Philippart Senior Software Engineer @Funding Circle. Overview. Context What is DDD ? Patterns we use Summary Q&A. Event-Driven Architecture. App B. App A. App C. How to create a well thought-out, effective, extensible design ?.

christofferse
Download Presentation

DDD in a Clojure Event-Driven Application

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DDD in a Clojure Event-Driven Application Gilles Philippart Senior Software Engineer @Funding Circle

  2. Overview • Context • What is DDD ? • Patterns we use • Summary • Q&A

  3. Event-Driven Architecture App B App A App C

  4. How to create a well thought-out, effective, extensible design ?

  5. Domain-Driven Design A set of tools to help designing and implementing complex software

  6. DDD levels Strategic Design • Deals with large models • Think about what matters most • Divide work between teams and integrate Tactical Design Manages complexity and ensure clarity of behavior within the domain model

  7. Strategic Patterns Bounded Context A bounded context is a part of your problem space. Things inside a context may have a different meaning in another one.

  8. Bounded Contexts REPAYMENTS PROCESSING LEGACY INVESTOR LOAN SERVICING DISTRIBUTION MONEY MOVEMENTS

  9. Strategic Patterns Ubiquitous Language A language that is developed by the team working in the Bounded Context and is spoken by every member of the team that creates the software model

  10. Shared understanding of the verbs and nouns Bring domain experts and developers Event Storming session Ubiquitous Language

  11. Strategic Patterns Context Mapping Context Maps define both team relationships and technical mechanisms that exist between two integrating Bounded Contexts Open Host Service Anticorruption Layer Conformist Published Language Customer-Supplier Big Ball of Mud Shared Kernel

  12. Customer-supplier and ACL REPAYMENTS PROCESSING LEGACY U U D ACL D INVESTOR D LOAN SERVICING U U D U REPAYMENT DISTRIBUTION MONEY MOVEMENTS D

  13. Use PL agnostic schemas (Avro) Publish the language in a visible place Control its evolution Published Language

  14. Loan Manager LOAN STATE 3 • CHECK • APPLY • UPDATE RepaymentReleased RepaymentReversed DefaultRequested RepaymentPaid ReversalApplied 1 2 LoanDefaulted 4 LOAN STORE

  15. Tactical Patterns Aggregate • Objects bound together by a root entity • Keeps model in valid state Loan Original Schedule Repayments Entry 1 Entry n Rep. n Rep. 1

  16. Tactical Patterns Event Sourcing • Keeps track of what happened in the aggregate • State is a reduction of event application { } + LoanOriginated {lent: 100} { remaining 100 status: live} RepaymentPaid {amount: 10} { remaining 90 status: live} + RepaymentPaid {amount: 10} { remaining 80 status: live} + RepaymentPaid + {amount: 80} { remaining 0 status: pre-paid}

  17. Implementation with Clojure and Kafka

  18. Implementation with Clojure and Kafka

  19. Tactical Patterns Hexagonal Architecture • Separate the domain logic & infra • Domain is “functional core” layer • Communicates with external world via ports and adapters P P P P P

  20. How we built our hexagons core-infra topology core-domain loan changelog loan aggregate topology events NO SIDE EFFECTS repayment paid topology loan store repayment reversed SIDE EFFECTS

  21. Use lein-modules

  22. Conclusion • Learn Domain-Driven-Design • Bounded Context separates domains • Published Language helps communicate • Aggregate controls change • Event Sourcing keeps history • Hexagonal Architecture untangles concerns DDD patterns solve specific problems, do not apply blindly

More Related