Talk given at MusterIt 2015. I'm trying to show here the difference that DDD makes, by describing knowledge that was available when the DDD was created and that has been used as a foundation of all DDD patterns and practices.

1. Genealogy of DDD
Szymon Homa
@s2lomon
s2lomon@gmail.com

2. Why it is important?

3. Entity
Examples of reference objects might include:
Customer, Account, Telephone Switch, and the like.
They are often complex and large and may be
referred to in lots of places. They usually have a rich
state and any change from any place needs to be
visible to other objects that refer to it.
Reference objects are compared based on their
identity, although you may see IdentifyingAttributes.
You don't usually see muliple copies of a
ReferenceObject in one address space.
Source: https://web.archive.org/web/20010717202923/http://c2.com/cgi/wiki?ReferenceObject
Reference Objects
Martin Fowler

4. Entity
Keep behavior with related information.
Don't make any role too big.
Distribute intelligence.
Keep information about one thing in one place.
Source: http://www.wirfs-brock.com/PDFs/A_Brief-Tour-of-RDD.pdf
Hints from RDD
Rebecca Wirfs-Brock

5. Entity
Source: https://domainlanguage.com/ddd/patterns/DDD_Reference_2011-01-31.pdf
In DDD Context
When an object is distinguished by its identity,
rather than its attributes, make this primary to its
definition in the model. Keep the class definition
simple and focused on life cycle continuity and
identity.
…
The model must define what it means to be the same
thing.
(aka Reference Objects)

6. Value Object
Source: http://c2.com/ppr/checks.html
CHECKS Pattern Language (Whole Value)
Ward Cunningham
…
Construct specialized values to quantify your
domain model and use these values as the
arguments of their messages and as the units of
input and output. Make sure these objects capture
the whole quantity with all its implications beyond
merely magnitude, but, keep them independent of
any particular domain.
…

7. Value Object
Source: https://domainlanguage.com/ddd/patterns/DDD_Reference_2011-01-31.pdf
In DDD context
When you care only about the attributes
and logic of an element of the model, classify it as a
value object. Make it express the meaning of the
attributes it conveys and give it related functionality.
Treat the value object as immutable. Make all
operations Side-effect-free Functions that don’t
depend on any mutable state. Don’t give a value
objectany identity and avoid the design complexities
necessary to maintain entities.

8. Specification
GoF StrategyGoF Strategy
Specification
(Martin Fowler and Eric Evans)

9. Ubiquitous Language
...
Revise the names of your objects to reflect their
ultimate roles. Words drawn from human relations
often imply much secondary meaning. Make sure
these align with the intent of your responsibility
allocations.
…
Avoid names that have confused or unfortunate
meanings in related domains. Consult a Thesaurus
and try the synonyms it suggests as you might use it
as a class name.
…
Your new names will lead you to an even deeper
understanding of your objects
System Of Names
Ward Cunningham
Source: https://web.archive.org/web/19961129215819/http://c2.com/cgi/wiki?SystemOfNames

10. Ubiquitous Language
Use the model as the backbone of a language.
Commit the team to exercising that language
relentlessly in all communication within the team and
in the code.
In DDD Context
Source: https://domainlanguage.com/ddd/patterns/DDD_Reference_2011-01-31.pdf

11. Domain Event?
Domain Service?
Repository?

12. Domain Event?
Domain Service?
Repository?
Events can be found in the
literature since the 80s.
Services are widespread in many
contexts, e.g. in RDD
DAO, Gateway, Service Provider

13. Aggregate?
Bounded Context?

14. Aggregate?
Bounded Context?
Simillar ideas can be found in RDD
Simillar ideas can be found in RDD

15. Time to see some code
https://github.com/S2lomon/genealogy-of-ddd-sketches

16. So again -
why it is important?

17. Questions