DDD eXchange

4,039 views

Published on

Following on from the success of last year, this annual event for London's architect community will have architectural innovation as a theme this year, and particularly CQRS. At the DDD eXchange we will feature leading thinkers and architects who will share their experience and Eric Evans is the programme lead.

Published in: Technology, Business
1 Comment
5 Likes
Statistics
Notes
  • For more details and podcasts from the DDD eXchange 2010 go to http://skillsmatter.com/event-details/podcast/ddd-exchange-2010
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
4,039
On SlideShare
0
From Embeds
0
Number of Embeds
1,695
Actions
Shares
0
Downloads
93
Comments
1
Likes
5
Embeds 0
No embeds

No notes for slide
  • That is a pretty dense statement. Over the next few hours, we’ll try to define enough terms and explain enough of what we concretely do in order to unpack this statement.
  • Explain briefly what a pattern is, what a pattern language is.All the DDD practices and patterns are based on observed, successful, repeated resolutions to important problemsAlthough we often make successful choices from intuition and experience, if we have no system or structure we are inconsistent. A pattern language systematizes and makes explicit the successful patterns of experienced people.An experienced, talented individual can make good decisions but have difficulty explaining to or collaborating with the other team members. A pattern language gives a team a standardized vocabulary for discussing options, tradeoffs and decisions.
  • That is a pretty dense statement. Over the next few hours, we’ll try to define enough terms and explain enough of what we concretely do in order to unpack this statement.
  • That is a pretty dense statement. Over the next few hours, we’ll try to define enough terms and explain enough of what we concretely do in order to unpack this statement.
  • DDD eXchange

    1. 1. Define DDD<br />Eric Evans<br />domainlanguage.com<br />
    2. 2. DDD is a Set of Driving Principles<br />Focus on the Core Domain. <br />Explore models in a creative collaboration of domain practitioners and software practitioners.<br />Speak a Ubiquitous Language within an explicitly Bounded Context.<br />
    3. 3. DDD isA Pattern Language<br />A set of interrelated problem/solution pairs that have helped teams realize the principles.<br />A vocabulary and conceptual framework for discussing domain modeling and design.<br />
    4. 4. Define Domain<br />domain A sphere of knowledge, influence, or activity.<br />
    5. 5. Define Model<br />model A system of abstractions that describes selected aspects of a domain.<br />
    6. 6. Mercator Map<br />
    7. 7.
    8. 8. The model we want…<br />Helps us solve specific problems in our domain.<br />Is not necessarily “realistic”.<br />Forms the basis of a language.<br />Is not the only model.<br />
    9. 9. Define Ubiquitous Language<br />ubiquitous language A language structured around the domain model and used by all team members to connect all the activities of the team with the software.<br />
    10. 10. Define Model<br />context The setting in which a word or statement appears that determines its meaning.<br />
    11. 11. Bounded Context An operational definition of where a particular model is well-defined and applicable. (Typically a subsystem, or the work owned by a particular team).<br />Define Bounded Context<br />
    12. 12.
    13. 13.
    14. 14.
    15. 15.
    16. 16.
    17. 17.
    18. 18.
    19. 19. Not all of a large system will be well designed.<br />
    20. 20. SubdomainPart of the domain, based on a particular conceptual decomposition of the domain. <br />Define Bounded Context<br />
    21. 21.
    22. 22.
    23. 23. Not Just Core Features;Core Domain<br />
    24. 24. DDD is a Set of Driving Principles<br />Focus on the Core Domain. <br />Explore models in a creative collaboration of domain practitioners and software practitioners.<br />Speak a Ubiquitous Language within an explicitly Bounded Context.<br />
    25. 25. Building Blocks<br />Entities<br />Value Objects<br />Services<br />Domain Events<br />Aggregates<br />Modules<br />
    26. 26. Aggregates<br />
    27. 27. Aggregate A cluster of run-time objects that are required to be consistent, whereas updates between aggregates may be asynchronous.<br />Define Bounded Context<br />
    28. 28. Service<br />
    29. 29. Service A significant process or transformation in the domain modeled as a stand-alone operation.<br />Define Bounded Context<br />
    30. 30. Domain Events<br />Something happened that domain experts care about.<br />
    31. 31. Domain Event Something happened that domain experts care about.<br />New information about activity in the domain modeled as a series of discrete events.<br />Define Bounded Context<br />
    32. 32. Safe or Out?<br />
    33. 33. These are not the same:<br />Subdomain– Decomposition of the domain.<br />Module – Decomposition of the model and associated software.<br />Aggregate – Decomposition of the run-time data.<br />Service – Decomposition of functionality.<br />Bounded Context – Linguistic boundary marking the applicability of distinct models.<br />
    34. 34. Areas Of Innovation<br />Event Sourcing, CQRS, <new name here><br />UdiDahan<br />Greg Young<br />Process Integration<br />GojkoAdzic<br />Eric Evans<br />
    35. 35. DDD is a Set of Driving Principles<br />Focus on the Core Domain. <br />Iteratively explore models in a creative collaboration of domain practitioners and software practitioners.<br />Speak a Ubiquitous Language within an explicitly Bounded Context.<br />

    ×