What is the best practice for writing a rather large wcf service, containing a lot of OperationContracts and DataContracts?
How would I separate functional areas into several contracts, would it be best to create an endpoint for each functional area?
Is there any way to keep the source for the different parts apart, but still use only one service for all of them?
Where do I get good information how to plan the contracts, what to include, how to split...?
That's been a big question surrounding services since their inception. SOA done successfully is SOA planned to the extent you're talking about. Having said that, I've always leaned more toward splitting services out, but using them in a composite manner. That is, several endpoints when you have several contracts, but most of them are only consumed by a few endpoints that are consumed by non-service callers. (wow, that was a mouthful, did it even make sense?)
Also, I would advise to have as few contracts as possible. Too many contracts can lead to poor manageability. Good contract design will help limit the number of endpoints and service calls. Removing OO concepts from contract design is one way of doing so. Contract design is a massive topic in itself, but suffice it to say that through good contract planning (up front), comes good service design.
Maarten Mullender writes a great blog on WCF design, and is a must read. There are also some great SOA/WCF books emerging as well.
Some good books:
This has been helpful to me it comes from the idesign.net website and it was authored by Juval Lowy:
I'll go off the track here and say I've used monolithic WCF contracts, functionally separated contracts (with a maximum of ten methods along Juval's guidelines in his book), and I've also tried a message handling architecture where a service has a single method that takes a base message, and handlers that 'know' how to unwrap and process the message after it crosses the wire.
I'm a big fan of the latter if you've got .NET on both sides of the fence. Oren has a screencast on the idea with code. I don't know what your needs are but this is working for me.
That said if you're already coming from "I need a large WCF service" then going to one method is probably not going to cut it for you. If that's true then Juval Lowy's Programming WCF Services is the standard you should uphold in your design.
I have a post here about how individual operations should differ from traditional code operations:
http://www.iserviceoriented.com/blog/post/Introduction+to+Service+Oriented+Architecture.aspx
You should end up only with operations for actual business events. If you ever stop and think "I need to enable transaction support on my web service" that means you haven't designed the operation with a wide enough scope. You should never have to enable web service transaction support.
I highly recommend Bill Poole's blog for higher level SOA concepts. Here's a post to get started: