How Domain-Driven Design (DDD) Can Hurt Your App

As we continue our journey into Domain-Driven Design (DDD): imagine a slingshot. It is simple. It has very few parts. You can probably make it yourself in your garage if you try.

This slingshot is like a startup.

Launching a startup does not require an app. Customers might simply fill out and scan a paper form (I'm not joking - there are successful startups that have done this). Shadow Testing, where you sell your product or service before it goes to market, or even before a prototype exists, can be a very important part of your startup's testing of product-market fit (think Kickstarter). You might present a prototype and ask people to preorder. Or you might just pitch the idea of what you intend to create and then ask people to sign up. Once you do start getting investors and can show that there is product-market fit, it's go time.

If you don't move fast, you die.

In this case, DDD is not an asset to your application. It is a fatal flaw.

Your startup, Fab Funds, allows anyone to purchase and sell video game credits on your exchange platform with anyone else. You have established product-market fit and are becoming known in the industry as the 'eBay for video game credits', although you are annoyed that the comparison to eBay is what has garnered a lot of attention. Your company is way cooler than eBay. One of the largest gaming expos in the world, LevelUp!, is happening just over a month from now, and Fab Funds is planning to present to a lot of industry leaders at the expo.

You wake up to a Slack message from your CTO on a Saturday morning that says: "BRUH - WE HAVE TO TAKE ADVANTAGE OF THIS..." He sends a link to a post on X from Stream, the number one online gaming platform:

We’re excited to announce Stream NFTs! Now you can win and trade NFTs of your favorite games by unlocking achievements, finding them in-game, or purchasing them through the Stream Store. Welcome to gaming in web3! — a fake X post

Your CTO has asked you to build a new Non-Fungible Token (NFT) trading module before the expo and have it operational so that the sales team can demo it. You’ll have to do the entire implementation end-to-end and then teach sales how to use it.

For simplicity, let’s assume there is an API provided by Stream where you can integrate with their platform without having to manage your own blockchain. You will need to:

• Add an NFT table to your PostgreSQL database to track what NFTs have been purchased by your users by adding foreign key references to it in the Orders table.
• Install and integrate the StreamNFT Python library with your backend Python API app.
• Create API endpoints that they UI can call in order to manager a customer’s NFTs.
• Build a UI where customers can see their NFTs, sell their NFTs, and view NFTs for sale.

If you choose to use DDD with a hexagonal architecture to do this, you will exponentially multiply your workload because you will have to:

• Figure out how to bootstrap a StreamFacade class into your Python API app that can interact with the Stream NFT lib, providing passthrough methods to the lib’s API, and then unit test each of those methods.
• Wire the StreamFacade service up to your API’s core domain service layer so that everything bootstraps correctly.
• Connect the new StreamNFT API controller and services to the new API core domain methods that call the Stream Facade.
• Then add new API endpoints
• Then create three UI views for viewing, selling, and browsing NFTs
• Create a UI ViewService for each of those three views
• Create UI core domain service methods that each ViewService can call
• Create ApiFacade service methods that the core domain methods can call.
• Create methods in your HttpService that call the new Python API endpoints.
• Unit test all interfaces between your various services, classes, and facades.

That doesn’t even include the PostgreSQL database changes, though that is a small thing considering the other work you have to get done. All the extra steps that DDD requires of you will take time that is already in short supply. To be fair to DDD proponents, I will note here that something like a more simplified layers architecture would be much more doable than a hexagonal architecture in a situation like this, but it still might be slow.

You decide that DDD is not worth it, because if Fab Funds doesn’t present at LevelUp! and bring in some investors the startup doesn’t have enough runway in its funding to last much longer. Future-proofing your app against the React UI framework you’re using being marked for End-Of-Life (EOL), against the StreamNFT Python lib’s API changing, and against your Python app’s Django framework requiring breaking changes to upgrade would be severe overkill. You just want to survive past LevelUp! So instead of DDD you choose to:

• Import the StreamNFT Python lib directly into your API‘s service layer and make new endpoints on the controller. You invoke the lib’s methods right there in your API logic, and on success or failure you write the results to the PostgreSQL NFT table.
• You make NftList, NftSell, and NftBrowse components in your React UI and make a simple set of hooks to call your new API endpoints using the fetch API.
• Unit tests are out of the question. You write three end-to-end Cypress tests that spin up the whole UI and go to the NftModule in the UI to then (1) view the NftList, (2) fill out the NftSell component’s form, and (3) pull up the list of NFTs available for sale, all by calling your development API environment directly. Your CTO thinks the Cypress tests are a little excessive, but you assure him that it will help you meet the deadline faster since you don’t have to manually smoke test every change.
• As a safeguard, you set up warnings in case the Cypress tests fail in GitHub Actions once a pull request is made to the main branch for the UI, but you still allow code with failing tests to be merged and immediately deployed to production. This prevents you from being stuck if the app is OK but your Cypress tests are mangled and you’re trying to push a last-minute fix.
• For the API, you have a test script that spins up the API and calls the new endpoints in GitHub Actions whenever a pull request is created to merge to main. You also set up merge permissions so that code with breaking tests can still be merged and deployed if you’re in a pinch.
• You also put the whole NftModule in the UI behind a feature flag so that you can turn it on for only your test users initially and quickly turn it off altogether if there are problems during the rollout. You can also gradually scale from 10% to 20% to 50% to 75% to 100% of your customers during rollout to production, and monitor for API and UI issues while you increase access.

Is this exhaustive test coverage? No, and you don’t care. It covers the primary happy path that sales will need to demo at the expo. You will use your best judgement as you make decisions to deploy the code or not if there are broken tests. If you’re lucky this feature and your job will last more than six months. You have just enough automated testing to ensure that the happy path stays healthy. It’s a small enough set of features that you can click through it manually in a couple of minutes, so you are ok with doing your own smoke testing whenever your changes go to production. If push comes to shove, the feature flag is your eject button and safety net that allows you to quickly turn off the module, figure out what went wrong, and then try again.

Instead of spending hours focusing on writing facades, passthrough methods, and unit tests you have spent that time on writing a few high value automated tests and creating some tools that enable you to very quickly go to production and if necessary roll back changes. The feature is ready on time, and the expo goes well.

Your startup, your app, and your job live to face the next quarterly report to your investors. Your hastily written feature module is a little brittle, and may not be maintainable for years to come, but it has served its purpose: getting more customers, investors, and revenue!