That's exactly one of the reasons why DTOs exists.
The tradeoff here is that adding DTOs makes your implementation a bit more complex, and thus prone to errors - such as a mismatch in mapping the domain object to a DTO. Use unit tests for this!
Another thing that you could do with your DTO and tends to be highly overlooked in RESTful services is treating hypertext data for references, nested objects and possible operations.
Refer to Martin Fowler's PoEAA:
"[...] it's worth mentioning that another advantage is to encapsulate the serialization mechanism for transferring data over the wire. By encapsulating the serialization like this, the DTOs keep this logic out of the rest of the code and also provide a clear point to change serialization should you wish."
http://martinfowler.com/eaaCatalog/dataTransferObject.html
TL;DR: I like the idea of separating the concerns of domain logic and "RESTful wiring" through DTOS, albeit introducing a more complex design.
Am I going about this the right way? Or am I maybe over-complicating it or missing something?
I think you have a start of a design; you are teasing out the concepts and their basic relationships and the constraints on the relationships, which is a great start.
For me, what I like to do is before I do any real detail on classes and operations (e.g. what methods, where business logic goes), I like to lightly enumerate the concepts and relationships in the business terms that create the ubiquitous language for a domain model. The concepts that have business identities (e.g. plane ticket with record locator, user having unique user name or id, etc...) will probably end up being aggregate roots. Ideally, these concepts and relationships are already known in the business and one doesn't have to try reinvent them as part of design. (And of course, iteration, improvements, refactoring, etc... will occur.)
Next, for me personally, having a good start at the concepts and relationships, I like to do application design from the ends toward the middle. I think of it a bit like designing a bridge. I like to have a design for the embankments first, then the middle (the span). In this analogy one embankment end is the persistence implementation, where I'm thinking about modeling concepts and also their relationships and some of their constraints with SQL using tables. The other end is the externally exposed interface, where I'm thinking about a REST API using OData principles.
I then design the classes, methods, and operations as a bridge that spans between the two, now-known embankments. Also note that we have many choices when it comes to class design (e.g. to use ORM or not, which classes get which methods and where business & application logic go), as the classes in the middle are closer to internal implementation and farther from externally exposed API.
I think you will want a formal notion of different kinds of Users (in addition to Developer), such as Business Stake Holder -- they might be the ones to initiate Projects.
The term event is overused in our business, so I try to use it only in a narrow way (my opinion is that an "event" is something that happened, once, either just now or in the past, and events can fire, be subscribed to, etc...). So, you might choose a more specific name within your business domain for what you are calling event. On the other hand, I'd probably move in the direction of more general recursively composed projects, so projects can compose/decompose into any number of other projects. You already have several specific layers of composition: Event, Project, Application, why not get more general? Yet still, recursive composition may not suffice, you may also need to track dependencies between projects (e.g between peer sub projects, or independent project that are not composed). I might try to formalize the notion of schedule along with notions of dependency.
For my aggregates, what do I do here? Do I write a "service" class like "TeamProjectService" with methods such as "CreateTeamProject"? Or what?
I have two comments here.
First, I would tend to think about the items you list in bold as aggregate roots as they probably have solid identities externally referable from outside the aggregate. Aggregate roots can be related to other aggregate roots (and for NxM relations I would model persistence for each of those with their own first-class table). The way you are using the term aggregate above makes me think about the relationships between aggregate roots more than the entities within the aggregate.
Second, I would probably do relationship creation via an operation attached to one or both of the aggregate roots being related. For example, a team entity might be able to create a project, or the project collection could create a project though requiring a team as a parameter.
These days, I like to use OAuth2 (e.g. Windows Live, Facebook, Google+, Twitter, Stackoverflow) for authentication (I do OAuth2 directly but perhaps Azure ACS can help abstract this across the variety of OAuth2 providers).
Best Answer
Domain Driven Design does not provide an answer for this. DDD is more focused on business logic. Your problem is how to represent data as a string of characters sent to and from a client across a network.
What you need is a Data Transfer Object (DTO). Any time you need to transfer data between processes, where the call to another process is the expensive part of the operation (as it usually is with HTTP requests) then you need a class or group of classes that specialize in the data that gets transmitted — not behavior — data, and data only. DTO's tend to have public getters and setters. They can be composed of other DTOs, but they should not contain any methods.
The structure of these DTO's can be used to serialize them into a string for transmission across a network, as in Service Oriented Architecture. While Martin Fowler recommends coupling the serialization and deserialization of DTOs together in the same object (which means adding methods to a DTO) this can also be accomplished with 3rd party libraries. Every tech stack has libraries for converting to and from JSON and XML, which are pretty standard data formats. These libraries often utilize class reflection to infer the data structure from the object members and type information.