Exact concerns and responsibilites of DDD elements

Question

I saw lots of articles regarding DDD and many patterns described in 'Patterns of Enterprise Application Architecture' By Martin Fowler book, yet i need DEVELOPMENT GURUS on stackoverflow help to understand few things.

What Is the main (methods and functionalists)=concerns that should be included in each of DDD components like (repository, aggregate root) and should it delegate it to other object ?

Aggregate Root Object eg. FaceBook , User is an aggregate roots that holds objects of UserObject(you),postObjects(posts you created),pictureOBJects; does the WORD Holds means it Hold it in its internal states ? or just that it hold a function that direct you to another Repository method including your id for example ?

cause if the Aggregate root hold aggregated objects in its internal state then what happens when an object is needed in more than 1 root ? (pictures also belongs to photoGallery),,, grrrrr I'm confused !

please describe for example Facebook(or any other webapp) domain design so noobs like me can establish an Ubiquitous Language between expert developers and us :)

Answer 1

cause if the Aggregate root hold aggregated objects in its internal state then what happens when an object is needed in more than 1 root ? (pictures also belongs to photoGallery),,, grrrrr I'm confused !

In DDD, entities are not always part of aggregation. Some entities that are shared by many aggregate roots are the roots of their own aggregates. They have their own repositories just like any aggregate roots. For example, in the blue book, Customer, Location, and CarrierMovement are shared entities that are roots of their own aggregates.

please describe for example Facebook(or any other webapp) domain design so noobs like me can establish an Ubiquitous Language between expert developers and us :)

DDD patterns can't be applied blindly or equally to any apps, they depend on how you and your team view the domain. For example, you aren't supposed to use aggregation pattern just because there is an containment relationship in your model. You can design: Customer owns Invoice, but you can also (more likely) design: Invoice has a reference to Customer. Both are valid in DDD.

Your design should really reflects the domain of your application. It should matches with your domain expert's point of view. The domain expert can be you yourself, your client or someone you hire because she is an expert in specific domain (eg: accounting, healthcare, banking, etc). Having domain expert in your team is a requirement in applying DDD. If your domain is not complex enough, you won't need DDD.