15

Say you were to develop a system which availability of entities and domain logic is highly dependent on user context. Would it make sense to handle the user context sensitivity within repositories by making individual repository instances user context aware? I'm considering adopting this methodology as a way pulling the reliance on user context away from my Entities but I'm not sure whether there are any pitfalls that I may not be aware of with going this direction. The way I'm planning approaching this first is to add a UserContext parameter to the constructors of repositories that need this context information. The other obvious option would be to feed user context information into each query method in my repositories but this would likely mean that the majority of all methods would require such parameter which would in turn greatly increase the verbosity of each method call.

Also I would like to point out that I'm aware that even if I am to make repositories user context aware that this does not necessarily help directly when a service or entity needs that same user context information for reasons such as determining behavior based on user configuration. I'm interested in other solutions for these cases as well but for now I'm trying to tackle one thing at a time so I'm focusing on the repositories first.

Any suggestions would be appreciated.

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
jpierson
  • 16,435
  • 14
  • 105
  • 149
  • 1
    @Nilesh agreed I think there's an interesting point here. @jpierson To clarify is the UserContext needed to provide/calculate Authorization for access to certain aggregates in your domain? Meaning admins have access to this Aggregate Root but regular users cannot retrieve them? – Kyri Sarantakos Mar 24 '11 at 19:12
  • @Kyri - Close, I have two cases where I need this context one is to validate values based on possible values the user has access to and the second is to set default values given a change in another value on an Entity. So an example could be a Contact entity which has a phone number and when the phone number changes it's area code should be validated to ensure it is one that the current user has jurisdiction over and if it is valid and the contact's City name is unset we are to default the City name with the value that corresponds to the area code. – jpierson Mar 26 '11 at 00:33
  • @josh - I've been holding off on this part of the design actually come up with something I feel is reasonable. If I end up moving forward with it I'll accept the closest related answer here on SO or I'll post my answer to explain what I did. You may also want to keep an eye on another closely related question of mine http://stackoverflow.com/questions/5454521/accessing-data-for-validation-and-determining-default-values-using-ddd. – jpierson Mar 31 '11 at 12:22

1 Answers1

1

I sense a design smell here :-). Things by the time they reach domain layer should pretty much be translated into domain entities/attributes and should not have dependency on context. What I mean is the context should be used to change/represent the new state of entity. Here it more seems like that context is going to be used to determine how the entity is going to be persisted. Have I understood this correctly?

Having said that, if your dependency on context is more from an infrastructure perspective rather than business functionality perspective then having context sensitive Repositories is the right model you have come up with.

Towards that, could you consider passing usercontext through thread local like Spring does with Hibernate Session? This way your Repository class's constructors or methods would be less polluted. It, however, does reduce the readablility of your code a bit.

Hope that helps.

Nilesh
  • 4,137
  • 6
  • 39
  • 53
  • @Nelesh - The main underlying problem that I'm trying to solve right now is that my validation rules in my Entity need information that is based on the current user in order to validate. The user context in this case holds information about what valid inputs are for that user. – jpierson Mar 21 '11 at 16:27
  • @jpierson - so that would be modelled in the entity i.e. these validations and the inputs they need will be passed to entity and eventually to persistence framework. – Nilesh Mar 22 '11 at 07:46