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.

Part 5 of this:

https://twitter.com/jesterxl/status/1310245921419034625

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.

rehanvdm.com/serverless/ref… 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.

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.

10 reasons why I love AWS Step Functions so much, illustrated using a JavaScript Promise chain:

step = json =>
service(params)
.then(flakyService())
.then(longService())
.then(({ id }) => Promise.all([send(id), audit(id)]))
.catch(log) 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)
=== [🍔, 🍟, 🍗, 🍿]