Case for Domain Driven Design

Updating code is a source of bugs. In an ideal world we would never update anything, instead we would just add functionality. But business rquirements change, our company pivots, or learns new information about the problem its solving. We need to make software that can change easily.

One way to do this is with Domain Drive Design. Its a big topic, but one characteristic DDD has is its layered structure. Here is one way you might seperate things:

• Domain (business logic)
• Infrastructure (connection definitions to outside world, aka repo, emitter)
• IO - outside conection setup

Testing anything involving outside services like databases, email services, payment systems, can br tricky, fragile, finicky, and time consuming. If we can make the code involving outside connections simple and small, then the tests will be less time consuming and finicky. This kind of code is also the kind of thing you dont want to have to update and change too often.

So what we can do is keep the io and infra as small as possible, and keep all business logic away from it. Business logic is the thing that will change the most, so lets try and keep as much of it as possible in the domain layer. What is great about domain code is its dependency on infra and io. When we test it, we can mock the infra, making it predictable and fast to test.

So in summary: Anything that changes can change for the worse. Testing infra and io is fragile and time consuming, so lets make those layers small, and prefer writing most of our code in the domain where its easy, fast, and predictable to test.