Reduce changes needed after adding a new field to domain object

Question

I'm developing an application with DDD pattern with three layers:

1. API
2. Domain
3. DB

After adding a new field to the domain object, I realized that many places need to change. Imagine the following model.

type TodoItem struct {
 UUId uuid.UUID
 Title string
 OwnerId string
 Project *Project
 IsDone bool
 Description string // new field
}

When the description field is added to the domain object, these places need to change:

1. API spec and controllers handling requests related to this object
2. All controller tests that might fail because of this field, for example, creating a new to-do item, have to include a new test to check the description is working as intended.
3. DB schema and functions that are working with DB to include this field. Also, the tests like the previous step

Is this amount of change normal? I think this is inefficient because these steps are not documented, and someone might forget(let's say they don't update previous tests to include the description field).

My approach: I'm thinking of somehow having functions in each layer to handle the fields, and when a new field is added, only that function needs to change.

Answer 1

Excellent observation. Is this normal? Answer: it is unfortunately. People don't seem to notice or care about this issue.

Every style / design / architecture that is based on separating technical aspects of the same business thing, like the "Clean Architecture", DDD, Hexagonal, DCI, Layered, etc.,has this same attribute. When things change, they usually change in multiple layers. Changes are rarely if ever localized, usually only if some limited technical things change.

I've written about this here and here.

So what can you do about it? Object-orientation to the rescue. Basically design in a way that related behavior is near to each other. You need the same knowledge to transfer money of an account and to display it? Co-locate it into the same object, for example Account.

If you don't expose data from objects (no getters basically), the above almost automatically happens.

Fair warning: if you try to move in this direction, you'll be mostly on your own. Designs following the above will look basically alien to anybody who thinks only in technical layering and technical separation. Good luck on your journey :)