Domain-driven design is a term coined by Eric Evans [1].
The goal behind domain-driven design is the collaboration between technical and domain experts.
A module should possess a cohesive set of concepts that can be reflected into the domain in order to develop an ubiquitous language. Modules must have low coupling between them at concept-level.
Talks to other systems through their interfaces and translates in every directions between models.
Shows information to the user and interpretes user's command.
Defines tasks which are meaningful to the business or necessary for interactions with other systems.
Represents concepts of the business, information about the business situation and business rules.
Provides generic technical capabilities that suppot the higher layers: message sending for the application, persistence for the domain, drawing widgets for the UI, and so on.
A value object is only defined by its attributes and should be immutable, it belongs to the domain layer.
An entity is not defined primarily by its attributes and should have at least one ID, it belongs to the domain layer.
An aggregate is a cluster of associated objects treated as a unit with an entity as root and boundary, it belongs to the domain layer. Associated objects should only be externally accessed from the root.
A factory has responsibility for creating instances of complex objects as a piece and then enforcing encapsulation, it belongs to the domain layer.
A repository has responsibility for storing instances of persistent objects with in-memory or database accesses, it belongs to the infrastructure layer and implements an interface which resides in the domain layer.
A service should be stateless, it belongs to the application, domain or infrastructure layer and implements an interface which resides in the same layer.
Services in the application layer should define tasks which are meaningful to the business or necessary for interactions with other systems.
Services in the domain layer should take non-natural responsibilities of entities or value objects.
Services in the infrastructure layer should be purely technical and lack any business meaning at all.
Services' names should be part of the ubiquitous language.
[1] Evans E. Domain-driven Design—Tackling Complexity in the Heart of Software. Addison-Wesley: Reading, MA, 2004.