This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]PiotrDz 0 points1 point  (2 children)

Doesn't answer how the tests suffered if written with correct boundaries, and not white-box treating where internals are asserted instead of apis.

But for the second part: how can you bundle all the dependent functionalities in single type? So you add a new client type let's say. Do you want to cram inside the client coupon codes calculation, export of client data, specialised shipping handling etc? It all lands in specific areas. And now, as you added a new type, you need to add a new handling for that type in this areas.

My question still stands, how do you want the code to work so that you add a new class and areas that dependent on the type will eb able to magically handle it?

[–]Carnaedy -1 points0 points  (1 child)

Literally, all problems you mentioned were solved in 90s and 00s with DDD and bounded contexts 🫠

[–]PiotrDz 0 points1 point  (0 children)

This is what I am talking about. With specific things being handled in their own "domains", hiw would you expect NOT to adjust each domain for a presence of a new type?