Marcus Mac Innes asks "I want to relate Users to Customers. Do I need to build a higher level service which offers additional interfaces (methods)? Or is it okay to let CustomerManagerService know a little about Users?"
James Avery writes "include the user id on the CustomManagerService, it is information about the customer and deserves to be on that service"
What makes me uneasy about this kind of discussion is the absence of any reference to the requirements. Before I make these kind of design decisions, to tie down (or encapsulate) the relationship between Customer and User, I'd want to know (among other things) how stable or volatile this relationship is.
Loose coupling isn't generally done to improve performance. It is typically done to improve adaptability, within the constraints of acceptable performance. We can't decompose to infinity, so we need to have some sense of where the adaptability is going to be most critical.
If your data structure is stable, then it may make sense to use this structure as the basis for your decomposition of requirements into services. But there are many business situations where the data structure isn't stable (or can only be stabilized by distorting or ignoring the true business/user demand) – and then we need to base the decomposition on some other design principle.
No comments:
Post a Comment