Anti-Corruption Layer – How to Design Anti-Corruption Layer in DDD

There is one thing I don't like about your design. And that is fact you are going to have 3 additional classes for each aggregate root (Factory, Mapper, Repository) with semi-duplicate code in form of reading and setting properties everywhere. This will be problematic as you add and remove properties, because forgetting to change a single method might cause an error. And the more complex the domain entity is, the more of this duplicate code is. I don't want to see CompanyFactory.CreateExisting when company has 10 properties and 2 entities in aggregate.

Second thing I might complain about is the IdentityFactory. In DDD, the identity should either be related to domain, in which case you set it to some calculated value. Or it is transparent, in which case you can have DB take care of it. Adding some kind of factory for identity is IMO overenginering.

I also don't like the mapping. While I agree it might not be possible to use EntityFramework directly, you could at least try. EF is getting better with POCO lately and you might be surprised how powerfull it is. But it still isn't NHibernate. If you really want to create separate models, try thinking about using some auto-mapping library.

It is nice you are demoing the design on one simple class, but try also demoing or at least imagining how the design will work with dozens of aggregates that have lots of properties and entities. Also, write a code that will use this design. You might realize that while the design might look good from the inside, it is cumbersome to use from the outside. Also, no one here is going to tell you if the design is appropriate for your team and your domain.

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).