4

I've seen lots of book and article examples saying to put validation code in your Service Layer. Keep the Domain Objects "dumb" (aka, pure POCO's) and handle all validation that a Domain Object might do in the Service Layer.

The Service Layer is responsible for so much it seems (or at least it can be); user authentication, role authentication, scripting dependency objects for IoC's (loggers, error-handlers, etc...), scripting Domain Objects, scripting repositories and passing Domain Objects to and from the repository... whew!

Doesn't creating all these rules in the Service Layer pose a substantial threat to your Domain Objects? For instance, what happens is some programmer decides to write consuming code directly against your Domain Objects and just bypasses the Service Layer altogether? That would be bad, but a believable situation.

If you are going to put a lot of the responsibilities in the Service Layer, including all Domain Object validation, is there a way to "protect" your Domain Objects is someone tries to script them directly? For instance, maybe some way your Domain Objects now they're not being used by a certain client (in this case, the Service Layer?).

Good design makes me think the Domain Objects should know nothing about who's calling them and how they're being called.

If there is no way to "lock down" the Domain Objects, then why are so many articles, books, etc suggesting that putting Domain Object validation in the Service Layer the way to go? I would imagine by taking a defensive programming position, that you should build your Domain Objects to be bullet-proof, and rely on your Service Layer for a simple layer of code to forwarding and receiving requests between the UI and the BAL/DAL.

Has anyone had some real-life project experiences with "abuse" of their Domain Objects from people that have bypassed their Service Layer?

Michael McCarthy
  • 1,502
  • 3
  • 18
  • 45

2 Answers2

2

I think you may misunderstand the purpose of a POCO. A POCO, as I understand it, is not an anemic domain object with only properties and attributes. Rather a POCO simply is not tied to a framework or complicated inheritance model. The object is flexible and only concerned about its role in the domain.

Aaron K
  • 51
  • 2
  • Agree with Joshua. Anemic domain model is considered an anti-pattern for many well defended reasons. From the man himself, http://martinfowler.com/bliki/AnemicDomainModel.html – Peter M. Elias Aug 11 '12 at 10:07
1

They are 2 different design philosophies. Rich Domain Model vs Anemic Domain Model.

The short answer is yes, you can prevent direct access to your domain objects.

You can do so with a number of techniques:

1) You can make all public facing domain objects immutable (i.e. you can't change the data) via only having the only public methods be getters. All methods that modify your objects can be protected or package private so only the correctly packaged services can access them (in Java at least)
2) You can expose only separate classes to your external developers -- so if you have a Person domain class you can have a PersonInfo class that you pass up, that does nothing but contain info.
3) You should expose a coherent API to your app consumers. You basically prevent them from bypassing your Service layer.

hvgotcodes
  • 118,147
  • 33
  • 203
  • 236
  • #2 sounds a lot like a Data Transfer Object, I think? I guess I could use a DTO, OR maybe return an interface that only exposes the properties I feel the end consumer should be able to set/get? I'll play around with some different approaches. I was hoping to avoid DTO's, as they can add another layer of complexity into a project. Thanks for the reply! – Michael McCarthy Mar 02 '11 at 15:47
  • @indiecodemonkey, yes it does. but the point is there are ways to lock down an api. – hvgotcodes Mar 02 '11 at 15:59