Gregor Hohpe discusses Domain Driven Design in Cloud, and hits 3 important topics:

1. How the words you use enable design, and indicate what type of work culture you’re in, and incentives to use better words.
2. How bad and difficult it is for Cloud providers to keep a consistent language, and to what degree they’ve created a decent set of words to describe their services, and how they could do better.
3. How most people do NOT get how to use AWS CDK.

I think 3 is the biggest take away for me. I spent way too much time trying to utilize Dhall to create a domain specific language for each project, and translate that to CloudFormation. Instead of thinking in Lambdas and Step Functions, you would use the language of the problem we’re trying to solve; the business of getting a Client’s(1) Accounts(2) into a bunch of PDF Financial Statements(3) that we could then put into a zip file called a StatementsZIP(4) and deliver to a customer’s FTP server.

Everything was modeled. I ensured low-level details such that you could NOT screw up us-east-1 vs. us-west-2 with the compiler ensuring everything was correct. No need to “test” if you could fail over to west from east; the compiler ensured that in seconds.

Ultimately, Dhall wasn’t verbose enough nor was I Dhall ninja, but something like TypeScript or ReScript probably would have been better.

This idea of using Domain Modelling, not just for language, but ensuring the compiler helps you ensure your cloud application works was kind of the point of the AWS CDK. However, whether Object Oriented or Functional, many people do NOT spend a lot of time domain modelling. Thinking long and hard with the team about a function name? Sure. Great thing to do, and clearly on the path of DDD, but creating a single language that everyone agree’s to use is key. Having 4 words for a Financial Statement is frustrating, causes confusion, and leads to bugs that could have been fixed if people just agreed to use the same word for a thing.

Gregor’s article gives you a high level on the 3 problems and it’s clear open source and marketing have a hard job in continuing to show why AWS CDK enables different, and better infrastructure as code options compared to AWS SAM or Serverless Framework. I’m almost inspired to try again for my ReScript to CloudFormation compiler…

https://architectelevator.com/cloud/ddd-technical-domains/