[Spearchucker]

"You pay for those boundaries with a convoluted mess of classes that describe the design pattern rather than the business logic. You end up with AbstractRequestInterfaceFactory type stuff."

I disagree. If a design (call it an architecture) is clean and coherent, it's obvious.

Because obviously a client must send the order to a server, which is protected by a gateway. And of course that gatway validates the client request, and the data coming in. And of course the server must have business rules to validate and process the order. And clearly the business components must call a data access component to persist the orders to a database. Simple, no?

[chii]

> Simple, no?

what happens when the business rule clashes with the database's constraint implementation, because different people either misinterpreted, or due to incompetence or miscommunication?

I think splitting up sounds great in theory, but in practise, has lots of pitfalls. That's not to say it's not a good idea, but one musn't look at it with rose-tinted glasses.

[Spearchucker]

Well you'd test, which would catch that scenario. Assuming you're not testing and discover it after releasing to production you'd just use your change process.

Either way this is just part of building a system. Refector, re-test and release (or re-release). It's hardly going to be the only bug you find.