Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In an oriented-services enterprise application, isn't it an antipattern to mix Service APIs (containing interface that external users depends on) with Model objects (entities, custom exceptions objects etc...) ?

According to me, Services should only depends on Model layer but never mixed with it.

In fact, my colleague told me that it doesn't make sense to separate it since client need both. (model and service interfaces)

But I notice that everytime a client asks for some changes, like adding a new method in some interface (means a new service), Model layer has to be also delivered...

Thus, client who has not interested by this "addition" is constrained to be concerned by this update of Model... and in a large enterprise application, this kind of delivery is known to be very risked...

What is the best practice ? Separate services(only interfaces so) and model objects or mix it ?

share|improve this question
up vote 1 down vote accepted

It depends on whether client is using exactly the same domain model as the server/service. Typically it doesn't, so they should be kept separate IMO.

share|improve this answer
In my case, they are shared with all clients. My reason to separate it is the following : Client A asks for a new need. This need does not impact Model objects since it used existing ones. So, no need for others clients to update the "shared model" for a functionnality they don't expect and eventually get existing functionnalities broken by some new ignored impacts/bugs (very frequent in large enterprise applications) – Mik378 Mar 23 '12 at 15:40

It sounds like you're referring to data models, not business models, and to me data models are just dumb data objects. Their sole purpose in life is to hold data, and they don't perform any business logic or functionality. There shouldn't be any problem with keeping them completely separate from the rest of the application code.

So typically my data models reside in their own library, which the business layers can reference, while business models will usually be part of the business layer.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.