Attempting again to learn Domain Driven Design, and it's clear if you're an Object Oriented Programmer trying to learn Functional Programming, no wonder you're confused. Here's a paragraph summary of the 500 page book I've translated each sentence into typed FP.
OOP: You model your business using Entities (the ID matters) and Value Objects (the values matter).

FP: You model your business using Types, Aliases, and Unions. Everything is immutable so has an implied ID, but you can add if you wish.
OOP: You use Repositories to retrieve and store them.

FP: You use functions to retrieve them. You can't store them as there is no state.
OOP: You create them with the help of Factories.

FP: You create them with with functions.
OOP: If an object is too complex for a single class, you’ll create Aggregates that will bind Entities & Value Objects under the same root.

FP: There are no classes, only functions that return immutable Types and Unions. Complexity just grows into more functions.
OOP: If a business logic doesn’t belong to a given object, you’ll define Services that will manipulate the involved elements.

FP: Objects don't have state or methods; you just create new functions return new values.
OOP: Eventually, when the state of the business changes (a change that matters to business experts), you’ll publish Domain Events to communicate the change.

FP: A function will get an input and return a value.
Caveat with the above is F# and Scala _do_ have classes and you can map your mental model of DDD around the boundaries. However, if you're doing Event Sourcing or CQRS, hopefully you can see how your life just got a lot simpler. (OOP people are thinking "dangerous")
Also, while "there is no state" in FP, there is always _someone_ who stores your state. The Database on the back-end, the Step Function in your infrastructure, the "Model" in Elm front-ends.
A lot of what I'm learning from researching DDD is the same thing the Agile crew uses Behavior Driven Design: learning the Business language, and modeling it into your code. Understanding the different types of users, the words they use, and making that strong types.
Learning business language is good. But if you remove stateful objects, then you're just left with functions. That means Aggregate, Service, Repository, and Factory are now just functions you compose together in a bigger function.
Bounded context isn't an OOP/FP thing, that's a monolith vs. microservice problem. If you're in an Elm front-end monolith, put in separate files. Back-end? Put in different Lambdas. Need to communicate? Use JSON schema/protobuff.
I'm glad my career with OOP ended before DDD became a thing. Yet here I am diving head first into learning this because 90% of what I read around Event Sourcing & CQRS assumes OOP, which isn't what I'm finding out in practice. The Akka Scala examples are these weird hybrids.
@jdegoes has a more hands on example here for how you'd design in Functional coding, where 90% of it is what you'd expect in typed FP and "class" is just because Scala is based on Java which has that as the core type despite being heavily typed FP.…
Caveat around dynamic languages like Python & JavaScript that support both OOP and FP styles; you can do the above, you just have less guarantee's at runtime, and the problems of bounded contexts bleeding into each other is the same as all monoliths: becoming a ball of mud.
It is extremely difficult reading these articles with my FP bias coming from OOP. Powering through anyway.

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with Jesse Warden

Jesse Warden Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @jesterxl

27 Sep
Part 5 of this:

Rehan van der Merwe has a great example here describing not only how to build a distributed monolith, but how to refactor it to microservices.…
Like me, he prefers Lambdaliths for API's despite the ease of API Gateway or Application Load Balancers make it to point to Lambda functions. I have other reasons because of the CICD pipeline my company forces us to use and our restricted list of AWS we can use.
It's important because he illustrates tight coupling that can happen. However, more important is how he _was_ able to build and deploy 3 microservices each on their own route hitting downstream systems, with e2e tests in place, ready to refactor.😀
Read 25 tweets
26 Jul
List of un-fun things you do as a developer that may be considered "senior":

1a. Architect an application you don't actually build. This includes pitch if applicable, creating visual diagrams of how it all works, & time estimations, effort, risks, & integration points.
1b. This is hard b/c if you have passion for coding, you _want_ to see your creation come into being, & want to help it become so by coding the fun parts. You don't. You _can_ do parts, sure, and sometimes it's your area of expertise. It's more impactful if you have others do it.
2a. Grooming. You've done enough projects that you have a general idea of 20-80% of the work. You might not know the minute details, but "build a login flow", "setup CI/CD", "do form validation on email". The key is answer either at story or epic level "what are we doing".
Read 39 tweets
23 Oct 19
10 reasons why I love AWS Step Functions so much, illustrated using a JavaScript Promise chain:

step = json =>
.then(({ id }) => Promise.all([send(id), audit(id)]))
1. You can think of Step Functions like `map`. The above takes json and returns json. They can feel like pure functions which makes unit testing straightforward.

map([🐮, 🥔, 🐔, 🌽], cook)
=== [🍔, 🍟, 🍗, 🍿]
2. service, flakyService, longService, send, audit, & log are all microservices. We orchestrate all of them into 1 function. Serverless & Server REST, on-prem SOAP, a 10 minute batch service, and a Kafka Message Queue message logging all wired together in 1 flow, 2 in parallel.
Read 14 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!