HanLHo. - Fractional Architect & Software Product Engineer - functional-programming

DDD and FP can be friends

2023-12-28T00:00:00+00:00

DDD (Domain Driven Design) is not tied to a particular programming paradigm and strategic and tactical design choices apply to the architecture and code level.

This article was triggered by a talk that does not align with my thinking and experience with DDD and FP over the past years: DDD and FP Can't Be Friends - Yet - Mike Sperber and Henning Schwentner - DDD Europe 2023</a>.

In response to "DDD and FP Can't be Friends"</h2>
To be honest, I'm not sure how to interpret the talk. It relies on stereotypes: the level-headed DDDer versus the overly eager 'let's start coding asap' Haskeller, and I expected some reconciliation at the end. Although there is some of that and the talk leaves room for both perspectives, I was disappointed because it seems to suggest that modelling in FP is more difficult than in OO, and that OO is better suited for DDD modelling, which I believe is not the case. At first, I thought these stereotypes were used for demonstration purposes, but as the talk progressed, I became less certain.
In the end, the title appears to reflect the talk's conclusion, which I disagree with. FP and DDD work well together, and in my opinion, the challenges presented apply to OO as well. On the other hand, the talk did prompt me to consider a few things I hadn't given much thought to before, which I will discuss further.
First of, if your takeaway from this talk is only its title, I encourage you to spend another 45 minutes listening to the Tech Lead Journal's podcast episode #79 with Mr. Scott Wlaschin</a> to understand how FP and DDD can 'be friends' quite effectively. He does a much better job than I can. (It's worth listening to regardless, including a fun analogy explaining why effectiveness is more important than efficiency, using the old TV series 'Murder She Wrote'.) Alternatively, for a deeper understanding, you can read the excellent book Domain Modelling Made Functional</a>.
And now to my notes:
DDD is not tied to any specific programming paradigm</h2>
DDD and FP are just as compatible as DDD and OO. OO's design patterns and object hierarchies can present challenges similar to those of the Monad and Applicative 'patterns' mentioned in the talk when it comes to modelling close to the domain. These abstractions are useful, and I would argue necessary, as they often result in better designs and more maintainable, bug-free code. In practice, we will likely use a ubiquitous language at the functional level and employ design patterns and abstractions for better software design. Interestingly, both approaches share the goal of building better software. Over-abstraction can be an issue for sure but my point is that this is not an issue solely linked to FP. Many factors can influence the paradigm choice and the extent to which abstraction levels and preciseness are modelled.
A strategic approach applies to architecture and code</h2>
While watching the talk, it seemed to me that it was more about tactical versus strategic approaches to modeling and programming, rather than FP versus DDD. I'm using the following definition of tactical vs. strategic because, to me, it clearly illustrates the short-term vs. long-term impact of the chosen approach. Words in brackets are my own.

"In tactical programming [modelling], the primary goal is to get something working quickly, even if that results in additional complexity; in strategic programming [modelling], the most important goal is to produce a great system design." (John Ousterhout, A Philosophy of Software Design, 2nd Edition) </blockquote>
In the talk both the DDD-practitioner and FP-practitioner advocate that their approach is strategically the most important, urging the other to be more tactical. For instance, the DDD-practitioner recommends writing code that works 'just enough' using TDD, while the FP-practitioner essentially wants to start coding immediately without considering the overall picture beforehand. However, in my opinion, they both operate at different levels of granularity, and at each level, it is worthwhile to pursue a DDD-inspired strategic approach (if part of your core domain but that's a whole different topic). If strategic design is important, it is important at the higher level and at the code level. It's not an 'either/or' choice.
First, define your architecture using bounded contexts and iterate until the value begins to diminish and risks are addressed. (E.g. by using a user journey, the talk shows a nice way of doing this.) Then, start coding. Until you actively work with the domain and 'encode' the knowledge of the domain in something visual or code-based, you are missing important details. While modelling the architecture and drawing diagrams is needed, and can feel very satisfying, getting something running connects to reality more than any other activity. The same applies to abstracting and refactoring code — do it until the value begins to diminish and risks are sufficiently addressed. In my experience, remodeling, refactoring, and abstracting for deeper understanding is often worth it. Knowing when to stop or continue is the challenge at each level.
When it comes to collaboration between business and implementers the key is to determine the appropriate level of abstraction where both can meet and discuss. BDD offers a method that encourages collaboration between domain experts and implementers based on a shared, non-technical specification. Modelling data and actions close to the domain as in DDD is another approach, be it OO or FP. The latter doesn't require domain experts to understand all the details of the code.
Rounding up</h2>
Finally some quick notes on smaller things from the talk I will not go into:

TTD and BDD are techniques used in FP as well. </li>

Haskell is not the only kind of FP. </li>

Immutability does not prevent changes to the domain. (It can even have benefits to modelling.) </li> </ul>
The perceived incompatibility between DDD and FP, as suggested by the talk, is not accurate. Both paradigms can be effective in their own right. The main takeaway is that DDD is not tied to a specific programming paradigm and that a strategic approach applies to both architecture and code, regardless of whether it's OO or FP. Techniques such as TDD and BDD, along with the right choice of programming language, can enable this successful collaboration. Ultimately, the choice between DDD and FP, or a combination of both, should be guided by the specific needs and constraints of the project at hand.

Simplifying if-complexity in FizzBuzz

2023-12-01T00:00:00+00:00

In this series, I've mentioned that using an if</code>-expression in the FizzBuzz problem can be more error-prone and complex compared to functional approaches. In this brief article, I'll demonstrate why that's the case.
Let's start with a simple working implementation using if</code>s:
// Commenting the Scala 3 version / Scala CLI directive //> using scala 3.3.1 def fizzbuzz(s: Int): List[String] = def shout(i: Int): String = if i % 15 == 0 then "FizzBuzz" else if i % 3 == 0 then "Fizz" else if i % 5 == 0 then "Buzz" else i.toString val fb: LazyList[String] = LazyList.from(1).map(shout) (fb take s).toList end fizzbuzz @main def fizzbuzz(): Unit = fizzbuzz(40).foreach(fb => print(fb + ",")) end fizzbuzz </code></pre> Suppose the requirement is now amended to include printing "Bazz" for every even number, such as printing "FizzBuzzBazz" at n = 30. // Commenting the Scala 3 version / Scala CLI directive //> using scala 3.3.1 def fizzbuzz(s: Int): List[String] = def shout(i: Int): String = if i % 30 == 0 then "FizzBuzzBazz" else if i % 15 == 0 then "FizzBuzz" else if i % 10 == 0 then "BuzzBazz" else if i % 6 == 0 then "FizzBazz" else if i % 5 == 0 then "Buzz" else if i % 3 == 0 then "Fizz" else if i % 2 == 0 then "Bazz" else i.toString val fb: LazyList[String] = LazyList.from(1).map(shout) (fb take s).toList end fizzbuzz @main def fizzbuzz(): Unit = fizzbuzz(40).foreach(fb => print(fb + ",")) end fizzbuzz </code></pre> It is clear that adding more words to this type of if-expression will cause it to expand rapidly and become increasingly difficult to get right. This is what I meant when I said extending the if</code>-expression is error-prone. Of course, this if</code>-expression is just the simplest and most commonly chosen solution by developers (I admit we've used this exercise as a hiring question as well), but that doesn't mean it can't be improved further, starting from its current state. Let's explore how to enhance it, beginning with using a mutable collection in the shout</code> function: def shout(i: Int): String = val sb = StringBuilder("") if i % 3 == 0 then sb.append("Fizz") if i % 5 == 0 then sb.append("Buzz") if i % 2 == 0 then sb.append("Bazz") if sb.isEmpty then i.toString else sb.toString() end shout </code></pre> Since the StringBuilder</code> is local to the shout</code> function, it doesn't break referential transparency, so I don't mind. However, what bothers me a bit more are the if</code>-statements that are no longer expressions, meaning they don't resolve to a value which is used further. Let's improve by defining a method with an explicit Unit</code> return type. The fact that a method returns Unit</code> indicates it is performing a side effect. def shout(i: Int): String = val sb = StringBuilder("") def maybeAppend(word: String, turn: Int): Unit = if i % turn == 0 then sb.append(word) else () maybeAppend("Fizz", 3) maybeAppend("Buzz", 5) maybeAppend("Bazz", 2) if sb.isEmpty then i.toString else sb.toString() end shout </code></pre> Putting the word-turn combination in a List</code> improves even more: def shout(i: Int): String = val sb = StringBuilder("") def maybeAppend(word: String, turn: Int): Unit = if i % turn == 0 then sb.append(word) else () List(("Fizz", 3), ("Buzz", 5), ("Bazz", 2)).foreach(maybeAppend) if sb.isEmpty then i.toString else sb.toString() end shout </code></pre> At this point inlining the maybeAppend</code> method again is probably more clear: def shout(i: Int): String = val sb = StringBuilder("") List(("Fizz", 3), ("Buzz", 5), ("Bazz", 2)).foreach: (word: String, turn: Int) => if i % turn == 0 then sb.append(word) else () if sb.isEmpty then i.toString else sb.toString() end shout </code></pre> As a final step in this article, we can then get rid of the mutable collection by using a foldLeft</code>: def shout(i: Int): String = val words = List(("Fizz", 3), ("Buzz", 5), ("Bazz", 2)) .foldLeft(""): case (acc, (word: String, turn: Int)) => if i % turn == 0 then acc + word else acc end words if words.isBlank then i.toString else words end shout </code></pre> The complete implementation becomes then: // Commenting the Scala 3 version / Scala CLI directive //> using scala 3.3.1 def fizzbuzz(s: Int): List[String] = def shout(i: Int): String = val words = List(("Fizz", 3), ("Buzz", 5), ("Bazz", 2)) .foldLeft(""): case (acc, (word: String, turn: Int)) => if i % turn == 0 then acc + word else acc end words if words.isBlank then i.toString else words end shout val fb: LazyList[String] = LazyList.from(1).map(shout) (fb take s).toList end fizzbuzz @main def fizzbuzz(): Unit = fizzbuzz(40).foreach(fb => print(fb + ",")) end fizzbuzz </code></pre> Extending this solution to even more FizzBuzz words is now as simple as adding an element to a list while the implementation only uses simple functions and is relatively easy to understand. We began this article by demonstrating that an initial if-expression-based solution for the FizzBuzz problem can be error-prone and complicated when expanded. Through step-by-step refactoring, we arrived at a solution using functional programming constructs. Our final solution is more future-proof and easily understandable, allowing for extensions with minimal effort.
FizzBuzz Functional Fun in Scala 3 2023-11-27T00:00:00+00:00 Nearly a decade ago, I wrote a post about implementing FizzBuzz in a more functional manner</a>, which also happened to be the final entry on a blog I started that year. Now, I want to dedicate more time to writing, and rebooting my blog seems to be a good way to achieve this. What better way to begin than by revisiting my previous post and picking up where I left off? I believe the article is still fine, but reading it feels like looking at old code I wrote: slightly awkward. Now, I would change some parts which I may do in upcoming posts but let's start simple and rewrite in Scala 3. This is the code I left with last time: def fizzbuzz(s: Int): List[String] = { // helper method inspired by haskell, cycle a list infinitely, def cycle(xs: List[String]): Stream[String] = Stream.continually(xs).flatten // a infinite cycle of "", "", "Fizz" val fizzes = cycle(List("", "", "Fizz")) // a infinite cycle of "", "", "", "", "Buzz" val buzzes = cycle(List("", "", "", "", "Buzz")) // zip the fizzes and buzzes, and concatenate them, result is "", "", "Fizz", "", "Buzz", "Fizz", ... val pattern = fizzes zip buzzes map { case (f, b) => f + b } // zip numbers with the pattern, if the pattern is empty keep the number, otherwise keep the pattern val numbers = Stream.from(1) val numbersAndPattern = numbers zip pattern map { case (n, p) => if (p.isEmpty) n.toString else p } numbersAndPattern take s toList } </code></pre> Below is a Scala 3 version in which I comment on the changes. Note that I added a Scala 3 version of a `main` function which can be run using Scala CLI.</a> // Commenting the Scala 3 version / Scala CLI directive //> using scala 3.3.1 // optional significant white spacing, we can omit all curly braces @main def fizzbuzz(): Unit = def fizzbuzz(s: Int): List[String] = // `Stream` is replaced with `LazyList`, the latter being fully lazy. def cycle(xs: List[String]): LazyList[String] = LazyList.continually(xs).flatten val fizzes = cycle(List("", "", "Fizz")) val buzzes = cycle(List("", "", "", "", "Buzz")) // case matches on tuples are not required anymore val pattern = fizzes zip buzzes map(_ + _) val numbers = LazyList.from(1) // again case match on tuples removed val numbersAndPattern = numbers zip pattern map: (n, p) => // if-then-else statement if p.isEmpty then n.toString else p // here extra braces are required (numbersAndPattern take s).toList // not required, explicit end clause for larger functions end fizzbuzz fizzbuzz(20).foreach(fb => print(fb + "," )) </code></pre> This will print 1,2,Fizz,4,Buzz,Fizz,7,8,Fizz,Buzz,11,Fizz,13,14,FizzBuzz,16,17,Fizz,19,Buzz,</code>. Most notable is the significant white spacing. I understand it is not to everybody's taste but I quite like it. I admit sometimes I get unexpected compiler errors because of it but nothing big not frequently. Another nice improvement which always was weird is that now the `case` matches on tuples can be removed when mapping. Cleaning up a little a removing superfluous comments I leave it at: // Commenting the Scala 3 version / Scala CLI directive //> using scala 3.3.1 @main def fizzbuzz(): Unit = def fizzbuzz(s: Int): List[String] = def cycle(xs: List[String]): LazyList[String] = LazyList.continually(xs).flatten val fizzes = cycle(List("", "", "Fizz")) val buzzes = cycle(List("", "", "", "", "Buzz")) val pattern = fizzes zip buzzes map (_ + _) val numbers = LazyList.from(1) val numbersAndPattern = numbers zip pattern map: (n, p) => if p.isEmpty then n.toString else p (numbersAndPattern take s).toList end fizzbuzz fizzbuzz(20).foreach(fb => print(fb + ",")) end fizzbuzz </code></pre> FizzBuzz Functional Fun in Scala 2014-02-23T00:00:00+00:00 Updated with a more functional implementation of FizzBuzz November 2015 Updated with a link to an implementation using Monoids</code> July 2016 FizzBuzz</a> fun in Scala using Scala Streams</a>. The straightforward implementation of FizzBuzz usually involves defining a list or array of fixed size 100, populating it using a loop over the index and setting the value in the list according to our Fizz Buzz specification. Streams</a> are lazy lists in which elements are only evaluated when they are needed. This allows for a seemingly infinite recursive loop-looking definition as shown in the Fibonacci example below. The first line builds a sequence of sums, the sum of a</code> and fibFrom</code> looks as it if it will never end if not for the lazy evaluation. def fibFrom(a: Int, b: Int): Stream[Int] = a #:: fibFrom(b, a + b) def fibonacciStream(n: Int) = fibFrom(1, 1).take(n).toList.last </code></pre> The 2nd line is there for clarity to show how to calculate the nth Fibonacci number based on our Stream</code> definition. The take</code> method will return a Stream, so nothing is being evaluated until toList</code> is called. (Note that in case of an infinite collection toList</code> may never terminate.) Here is an alternate implementation of FizzBuzz using the Stream</a> class in the standard Scala API. def fizzbuzz(s: Int): List[String] = { def shout(i: Int): String = if (i % 15 == 0) "FizzBuzz" else if (i % 3 == 0) "Fizz" else if (i % 5 == 0) "Buzz" else i.toString val fb: Stream[String] = Stream.from(1).map(i => shout(i)) (fb take s).toList } </code></pre> Stream.from(start:Int)</code></a> creates an infinite stream of integers and we map them using a function according to the FizzBuzz specification. We then take the first n</code> of this infinite list and convert it to a 'normal' Scala List. To print the first 100: fizzbuzz(100).foreach{ println(_) } </code></pre> As a little extra, this is how we could test our FizzBuzz implementation using ScalaCheck</a>: import org.scalacheck.Gen import org.scalatest.FunSuite import org.scalacheck.Prop.forAll import org.scalatest.prop.Checkers class FizzBuzzTest extends FunSuite with Checkers { test("fizzbuzz") { val fb = fizzbuzz(100) val range = Gen.choose[Int](1, 100) val fizzbuzzProperty = forAll(range) { n => if (n % 15 == 0) fb(n - 1) == "FizzBuzz" else if (n % 5 == 0) fb(n - 1) == "Buzz" else if (n % 3 == 0) fb(n - 1) == "Fizz" else fb(n - 1) == n.toString } check(fizzbuzzProperty) } } </code></pre> A more functional implementation of FizzBuzz (added November 2015) Thanks to Dierk König's implementation in Frege</a>: def fizzbuzz(s: Int): List[String] = { // helper method inspired by haskell, cycle a list infinitely, def cycle(xs: List[String]): Stream[String] = Stream.continually(xs).flatten val numbers = Stream.from(1) // a infinite cycle of "", "", "Fizz" val fizzes = cycle(List("", "", "Fizz")) // a infinite cycle of "", "", "", "", "Buzz" val buzzes = cycle(List("", "", "", "", "Buzz")) // zip the fizzes and buzzes, and concatenate them, result is "", "", "Fizz", "", "Buzz", "Fizz", ... val pattern = fizzes zip buzzes map { case (f, b) => f + b } // zip numbers with the pattern, if the pattern is empty keep the number, otherwise keep the pattern val numbersAndPattern = numbers zip pattern map { case (n, p) => if (p.isEmpty) n.toString else p } numbersAndPattern take s toList } </code></pre> What I like about this implementation: Much fewer conditionals. There is only 1 compared to 4 in the first implementation. And the order matters in the latter, if I do not put the i % 15 == 0</code> check first the logic will fall apart. So if changes need to be made it is easier to introduce bugs in the one containing more conditionals. </li> The code can be more easily built incrementally using the REPL. It just flows nicer. The shout</code> method needs to be entered in one go, all or nothing. </li> Closer to the specification. Consider the i % 15 == 0</code> check in the first implementation a bit more: to fit the FizzBuzz specification better it would be more accurate to write it as i % 3 == 0 || i % 5 == 0</code>. This would up the conditional checks to 5 though. At first sight, the concatenation in the functional implementation felt like a lucky shot, but in fact, it fits exactly the specification of FizzBuzz: I suppose it is no coincidence we are shouting 'FizzBuzz', a concatenation, instead of 'Boo!'. </li> </ul> Note there is also zipWithIndex</code> in Scala but I maintained the same "zip</code> and map</code>"-logic to keep the code more consistent and hence more simple. A functional implementation using Monoids</code> (Added July 2016) Monoids also provide a way of implementing FizzBuzz in a more functional way, check it out here</a>. At the moment I do not have the time to go into detail but it is a nice example of practical use of monoids.