• Save

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Up to speed in domain driven design

on

  • 1,435 views

A presentation I held about a year ago at the Dutch DDD user group

A presentation I held about a year ago at the Dutch DDD user group

Statistics

Views

Total Views
1,435
Slideshare-icon Views on SlideShare
1,434
Embed Views
1

Actions

Likes
3
Downloads
0
Comments
0

1 Embed 1

http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Up to speed in domain driven design Up to speed in domain driven design Presentation Transcript

    • Up to Speed in Domain Driven Design Rick van der Arend rvdarend@sogyo.nl
    • Agenda  What is Domain Driven Design?  An example of a domain model  The building blocks of a domain model  Refactoring towards deeper insight  What has been learned since the book?  Wrap-up SOFTWARE INNOVATORS 2
    • What is DDD? “Putting the Domain Model to work” SOFTWARE INNOVATORS 3
    • DDD in one sentence  Domain Driven Design is a style of software development which focuses on removing translation barriers between domain, development team and design of working software using a ubiquitous language supported by a well refined living model.
    • Translation barriers  Team talks to users and experts (if lucky)  Write software that behaves as requested  Names get translated back and forth  Concepts diverge without anyone noticing ? SOFTWARE INNOVATORS 5
    • Domain, Team and Model Ubiquitous Language
    • Origins of the acronym DDD  Eric Evans wrote the book that gave the acronym DDD an impulse in 2005. Aptly named: Domain Driven Design “Tackling Complexity in the heart of software”
    • An Example of a domain model SOFTWARE INNOVATORS 8
    • Domain model Orthogonal to the sun‟s plain of movement Turning during the year Parallel to the equator Parallel to the earth axis SOFTWARE INNOVATORS 9
    • From Phased to Iterations Analysis Design Build Test Iteration Iteration
    • Start with the Model, don’t stop Iteration Iteration Domain Model effort as part of an iteration SOFTWARE INNOVATORS 11
    • The building blocks of a Model-Driven Design SOFTWARE INNOVATORS 12
    • Building blocks of MDD
    • Entities & Value objects  Entities have an unmistakeable identity  Value objects are indentified by.. their value  a Person  a Name  an Address  This depends on.. of course.. Context!
    • Factories , Repositories, Aggregates  Factories create, Repositories store  The unit of work they work on is an aggregate  The thing they create of find and hand over will be a reference to the aggregate root
    • Services  Services encapsulate... well… Services  They are not part of the core domain, but linked  Objects change into other objects
    • Layers.. and more  UI > domain model > Data access  Or.. domain model depends on nothing SOFTWARE INNOVATORS 17
    • Refactoring towards deeper insight SOFTWARE INNOVATORS 18
    • Refactoring towards deeper insight  Use patterns when appropriate  Make Unit Tests  Better yet, do TDD  Better yet, do BDD  DRY and YAGNI  But: all a bit technical
    • Making Implicit Concepts explicit  Listen to Language  Scrutinize Awkwardness  Contemplate Contradictions  Read the Book  Try, Try again  Model the less-than-obvious: constraints, processes, commands, relations, etc.
    • Strategic Design SOFTWARE INNOVATORS 21
    • Contents of chapter 4 as a model
    • Strategic Design: context rules!  Be aware of different contexts  Make a context map  See how different bounded contexts relate  Shared Kernel, Customer/Supplier development teams, Conformist, Separate Ways, Partner  Use an anti-corruption layer
    • Context Maps step-by-step 1. What models (or BBoM) do we know of? (draw blob each and name it.) 2. Where does each apply? (Boundary in words.) 3. Where is information exchanged? (Connect) 4. What is the relationship? (Upstream/downstream? Partner? Etc.)
    • What has been learned since the book? SOFTWARE INNOVATORS 25
    • Highlights that Evans learned  Building blocks are overemphasized  But domain events added as a new type of block  General advice ▫ Don‟t spread modeling too thin ▫ Focus on the core domain ▫ Clean, bounded context (CM steps available) ▫ Iterative process ▫ Don‟t bore your domain experts
    • Domain events taken further  Greg Young has been promoting the idea of Command and Query separation
    • Techniques to explore  Exploratory Modeling (xM)  Model Driven Development environments  Language Workbenches  Naked Objects and other such platforms SOFTWARE INNOVATORS 28
    • Quick Wrap-up SOFTWARE INNOVATORS 29
    • Summary  DDD highlights aspects of software design  It focuses on the „core domain‟ and uses a ubiquitous language, based on a domain model  The ubiquitous language brings out flaws  A Domain Model is normally made up of certain types of building blocks  Thinks about context too: take control where and whenever possible
    • Resources for Further study  http://www.domaindrivendesign.org  Numerous articles on http://www.infoq.com  http://www.slideshare.net/devnology/unleash- your-domain-with-greg-young
    • DDD in C#  Jimmy Nilsson applied it to a C# context. His book is has an informal tone, but a bit noisy. Applying DDD and Patterns With Examples in C# and .NET
    • Contact Rick van der Arend rvdarend@sogyo.nl 030 - 220 22 16 Web: www.sogyo.nl Blog: www.software–innovators.nl SOFTWARE INNOVATORS 33