Functional Patterns in Domain Modeling - Debasish Ghosh

Domain modeling has traditionally been viewed and implemented using OO techniques and class based OO languages. The focus being the domain itself, existing literature has espoused us to start looking into the nouns of the domain. Classes first, accompanied with deep nested inheritance hierarchies form the backbone of many domain model implementations today.
In this talk we will take a radically different approach. We will start with a focus on the verbs first, think about domain behaviors and how we can model them using pure functions grouped together within extensible containers called modules. We will take an algebraic approach towards evolution of these modules, the algebra being composed of functions, types and laws. We will see how the domain algebra can be constructed as a composition of algebras from standard categorical structures like monoids, functors and monads.
We will conclude the talk with an introduction to property based verification of domain laws which are essentially the properties of the domain algebra. The discussion will be based on Scala and we will make heavy usage of the static type system that the language offers.

[@satvistayou]

Excellent talk. Presentation of some terrific concepts which we can use in building our Line of Business Applications.

[@carnelyve866]

Excellent excellent talk. Very practical.

[@bernardputersznit64]

The talk is marvelous. Thanks.
However, the washed out flickering projection is murderous. Be more careful going forward.

[@tacoman12345]

This is a great presentation, and working through it has really helped me understand how to define a domain algebra (and combine that algebra with existing categorical algebras) in a way that cleanly separates the syntax of the algebra from various context-specific semantics (interpreters). However, I have a question about the use of type bounds (starting at ~20:06) to enrich the algebra: at this point, the execute method is refined so that it can only a BrokerAccount (def execute[Account

[@DebasishGhosh]

+Timothy Perrigo Glad that you liked the presentation. It's certainly possible to carry on the type constraints downstream. I have intentionally removed them for simplicity of presentation and to reduce code clutter in the slides. And also they were not much relevant in the topics that I covered next. The idea was to demonstrate the composition of algebra. However I will prepare a sample of what u have mentioned - composition with Kleislis + type bounds and post it here. Am I bit tied down atm - watch out this space for some code ..

[@tacoman12345]

+Debasish Ghosh Thank you so much! I suspected that brevity was the reason that the type constraints were not used in later examples, but since I am still very much a novice in this regard, having a concrete example of something like the Trading module (and the generateTrade function implemented using the Kleisli 'andThen' combinator) with the type constraints in place would be extremely valuable and help me understand how to maintain compositionality while enriching the algebra. I truly appreciate all of your effort (There's certainly no rush...I'll keep an eye on this space!)

[@DebasishGhosh]

+Timothy Perrigo Here's a simple example that I cooked up .. gist.github.com/debasishg/7ff771bb695c2a330ccb. It involves type constraints as part of the module algebra as well as composition of domain behaviors with Kleisli. Let me know if u need more details ..

[@tacoman12345]

+Debasish Ghosh Perfect! Thank you so much!

[@stellacarlin9366]

+Debasish Ghosh rfzc

[@channel-ug9gt]

Are the slides available somewhere ?

[@sombhattacharyya]

www.slideshare.net/debasishg/qconny-12

[@SteveJonesHimself]

This looks like much earlier, very different talk (despite the shared name). Actually, that brought me here. :)