January 5, 2020

Domain Modeling Made Functional

Speaker

Scott Wlaschin, Creator of F# for Fun and Profit

Thoughts

Interesting talk about domain driven design. We are not deliberate doing this at work now, but as the financial sector is so complex we rely heavily on domain experts to define what we should build.

But what I experienced first hand was the implementation details being naively done following a poorly specific design by experts. The quote from the talk "communication is two-way" is really important and in order to be able to have this conversations, the developer must understand about the domain as well.

As I already stated in other posts, I see very small engagement of the developers of my team to understand better the domain we are working on. Sometimes I think that this is because the amount of deliverables we are dealing at the moment.

Need to fix that

Quotes

Object-oriented programming is scary

Functional programming is really good for boring, line of business applications

The Verbs or the Actions are represented by functions

It’s not just about the result. The process of building the shared mental model is critical!

A function is a thing which transforms inputs to outputs

A type is just a name for a set of things

Make illegal states unrepresentable. Yaron Minsky

Recomendations

  1. Design helps you to reduce the garbage input in your process

  2. Agile contribution: Rapid feedback during design stage

  3. DDD contribution: Shared mental model of the solution

  4. When you are designing you ask a lot of dumb questions. We are not the experts.

  5. Communicate the design in the code

  6. Modeling constrained values

  7. Replacing boolean flags with choices

  8. Communication is two-way. It’s OK to push back

  9. Use code to represent the shared mental model and ubiquitous language

  10. Design will evolve. Embrace change.

  11. Refactor towards deeper insight

  12. Use the power of a composable type system

Tags: design ddd functional