Scott Wlaschin, Creator of F# for Fun and Profit
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
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
Design helps you to reduce the garbage input in your process
Agile contribution: Rapid feedback during design stage
DDD contribution: Shared mental model of the solution
When you are designing you ask a lot of dumb questions. We are not the experts.
Communicate the design in the code
Modeling constrained values
Replacing boolean flags with choices
Communication is two-way. It’s OK to push back
Use code to represent the shared mental model and ubiquitous language
Design will evolve. Embrace change.
Refactor towards deeper insight
Use the power of a composable type system