Re:Better Software Design with Clean Architecture
by chii on Monday July 03, 2017 @07:32AM
(#14687465)
> 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.
Re:Better Software Design with Clean Architecture
by Spearchucker on Monday July 03, 2017 @05:21PM
(#14691495)
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.
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?