DDD what all terms mean for Joe the plumber who can't afford to read books few times?

I am on a tight schedule 开发者_StackOverflow中文版with my project so don't have time to read books to understand it.

Just like anything else we can put it in few lines after reading books for few times. So here i need some description about each terms in DDD practices guideline so I can apply them bit at a piece to my project.

I already know terms in general but can't put it in terms with C# Project.

Below are the terms i have so far known out of reading some brief description in relation with C# project. Like What is the purpose of it in C# project.

• Services
• Factories
• Repository
• Aggregates
• DomainObjects
• Infrastructure

I am really confused about Infrastructure, Repository and Services When to use Services and when to use Repository?

Please let me know if anyway i can make this question more clear

I recommend that you read through the Domain-Driven Design Quickly book from infoq, it is short, free in pdf form that you can download right away and does its' best to summarize the concepts presented in Eric Evan's Blue Bible

You didn't specify which language/framework the project you are currently working on is in, if it is a .NET project then take a look at the source code for CodeCampServer for a good example.

There is also a fairly more complicated example named Fohjin.DDD that you can look at (it has a focus on CQRS concepts that may be more than you are looking for)

Steve Bohlen has also given a presentation to an alt.net crowd on DDD, you can find the videos from links off of his blog post

I've just posted a blog post which lists these and some other resources as well.

Hopefully some of these resources will help you get started quickly.

This is my understanding and I did NOT read any DDD book, even the holy bible of it.

• Services - stateless classes that usually operate on different layer objects, thus helping to decouple them; also to avoid code duplication
• Factories - classes that knows how to create objects, thus decouple invoking code from knowing implementation details, making it easier to switch implementations; many factories also help to auto-resolve object dependencies (IoC containers); factories are infrastructure
• Repository - interfaces (and corresponding implementations) that narrows data access to the bare minimum that clients should know about
• Aggregates - classes that unifies access to several related entities via single interfaces (e.g. order and line items)
• Domain Objects - classes that operate purely on domain/business logic, and do not care about persistence, presentation, or other concerns
• Infrastructure - classes/layers that glue different objects or layers together; contains the actual implementation details that are not important to real application/user at all (e.g. how data is written to database, how HTTP form is mapped to view models).

Repository provides access to a very specific, usually single, kind of domain object. They emulate collection of objects, to some extent. Services usually operate on very different types of objects, usually accessed via static methods (do not have state), and can perform any operation (e.g. send email, prepare report), while repositories concentrate on CRUD methods.

DDD what all terms mean for Joe the plumber who can’t afford to read books few times?

I would say - not much. Not enough for sure.

I think you're being quite ambitious in trying to apply a new technique to a project that's under such tight deadlines that you can't take the time to study the technique in detail.

At a high level DDD is about decomposing your solution into layers and allocating responsibilities cleanly. If you attempt just to do that in your application you're likely to get some benefit. Later, when you have more time to study, you may discover that you didn't quite follow all the details of the DDD approach - I don't see that as a problem, you proabably already got some benefit of thoughtful structure even if you deviated from some of the DDD guidance.

To specifically answer your question in detail would just mean reiterating material that's already out there: Seems to me that this document nicely summarises the terms you're asking about.

They say about Services:

Some concepts from the domain aren’t natural to model as objects. Forcing the required domain functionality to be the responsibility of an ENTITY or VALUE either distorts the definition of a model-based object or adds meaningless artificial objects.

Therefore: When a significant process or transformation in the domain is not a natural responsibility of an ENTITY or VALUE OBJECT, add an operation to the model as a standalone interface declared as a SERVICE.

Now the thing about this kind of wisdom is that to apply it you need to be able to spot when you are "distorting the definition". And I suspect that only with experience (or guidance from someone who is experienced) do you gain the insight to spot such things.

You must expect to experiment with ideas, get it a bit wrong sometimes, then reflect on why your decisions hurt or work. Your goal should not be to do DDD for its own sake, but to produce good software. When you find it cumbersome to implement something, or difficult to maintain something think about why this is, then examine what you did in the light of DDD advice. At that point you may say "Oh, if I had made that a Service, the Model would be so nmuch cleaner", or whatever.

You may find it helpful to read an example.: