Everything is either a Service, Entity, or Value

First, remember that everything in your system is either a Service, Entity or Value. I didn’t make those names up: I learned them from Eric Evans in Domain-Driven Design.

https://blog.thecodewhisperer.com/permalink/when-is-it-safe-to-introduce-test-doubles

Bounded Contexts

People are talking about two entirely different things when they chat about a policy in the context of a general workflow versus a policy in the context of payroll auditing. If you use the same policy class, you're fattening the profile of that class and getting a long way from tried-and-true best practices such as the Single Responsibility Principle (SRP).
Systems that fail to isolate and insulate Bounded Contexts often slip into an architectural style (amusingly) called The Big Ball of Mud. ... 
When you use modules (or namespaces) to divide up your model, you really want to question whether you're dealing with a separate context. The cost of cleaving out another context is usually much higher: now you have two models, likely in two assemblies, that you need to connect with application services, controllers, and so on.

http://msdn.microsoft.com/en-us/magazine/dd419654.aspx