Domain Driven Design Implementation Patterns and Considerations in

  • Slides: 33
Download presentation
Domain Driven Design Implementation Patterns and Considerations in. NET

Domain Driven Design Implementation Patterns and Considerations in. NET

Who am I? • …and why should you care? • Steve Bohlen • I

Who am I? • …and why should you care? • Steve Bohlen • I Read Books + Write Software • vs. “Read Software + Write Books” • Blog, Screencast, Speak, Share, Learn

Nearly 20 years developing software LISP, Delphi, C/C++, VB. NET, C# Co-Founder, NYC Alt.

Nearly 20 years developing software LISP, Delphi, C/C++, VB. NET, C# Co-Founder, NYC Alt. Net User Group http: //nyalt. net Contributor: various OSS projects http: //www. summerofnhibernate. com blog: http: //blog. unhandled-exceptions. com e-mail: [email protected] com twitter: @sbohlen

Virtual. Alt. Net • • • Meets weekly (monthly? ) 9: 00 pm EST

Virtual. Alt. Net • • • Meets weekly (monthly? ) 9: 00 pm EST Livemeeting-based http: //www. virtualaltnet. com Alt. NET Topics Past Speakers: – Ayende (Oren Eini) – Jeremy Miller – Lesser-known people (like myself)

NYC Code. Camp • • March 6 th , 2010 Registration opens February 8

NYC Code. Camp • • March 6 th , 2010 Registration opens February 8 th (Monday!) http: //nyc. codecamp. us Alt. NET –focused topics – Sharepoint and Silverlight too (if you‘re into that!) • Come heckle Rachel Appel (the new NYC-area MS Developer Evangelist)

http: //tinyurl. com/badnay

http: //tinyurl. com/badnay

http: //tinyurl. com/b 55 f 6 q

http: //tinyurl. com/b 55 f 6 q

http: //tinyurl. com/ykv 4 tf http: //tinyurl. com/58 yf 3 k

http: //tinyurl. com/ykv 4 tf http: //tinyurl. com/58 yf 3 k

Beta Presentation

Beta Presentation

Opinions Ahead

Opinions Ahead

Agenda • Concepts Behind DDD (as needed) • Implementation Patterns and Concerns for DDD

Agenda • Concepts Behind DDD (as needed) • Implementation Patterns and Concerns for DDD Model Building Blocks in C# • General DDD Coding Anti-Patterns • Domain Entities • Domain Value Objects • Domain Repositories • Domain Services • Domain Validation • Discussion

Common DDD Coding Anti-Patterns • DDD Constructs with ‘type-suffixes’ • ‘Types’ are ‘roles’ in

Common DDD Coding Anti-Patterns • DDD Constructs with ‘type-suffixes’ • ‘Types’ are ‘roles’ in the Domain Model • Not… • Customer. Entity • Address. Value. Object • Customer. Repository • Shipping. Service • Overdue. Order. Specification • Repository as glorified DAL • repository. Get(int id) • repository. Save(Customer c) • repository. Delete(Customer c) • repository. Update(Customer c)

Entities

Entities

Coding DDD Entities Distilled • Identity Equality – Objects are just reference-equal by default

Coding DDD Entities Distilled • Identity Equality – Objects are just reference-equal by default in. NET – Equals, Get. Hash. Code, IEquatable<T> • Identity Comparison • Control of Access to Children Objects within the aggregate – Customer. Add. Order(the. Order); , Customer. Remove. Order(the. Order); – Not Customer. Orders. Add(the. Order); • Infrastructure-Ignorant – Persistent-Ignorant, UI-Ignorant, etc.

Challenges with DDD Entities • Do we expose Identity value as a property? –

Challenges with DDD Entities • Do we expose Identity value as a property? – Isn’t that a persistence-concern? – Providing a setter means the ‘identity’ of my entity can be changed by something external to it (bad!) • Are General Property Setters/Getters a smell? – Means your domain is trending towards DTO-hell – Entities as property-containers for data – Non-Meaningful names for things!

Exploring Entities in Code

Exploring Entities in Code

Value Objects

Value Objects

Coding DDD Value Objects Distilled • Immutable – After construction, no changes to the

Coding DDD Value Objects Distilled • Immutable – After construction, no changes to the object – Read-Only Properties • Value-Equality – Equals, Get. Hash. Code, IEquatable<T> • Property-by-Property comparison!

Challenges with DDD Value Objects • Tedious to write boilerplate IEquatable<T> implementation code by

Challenges with DDD Value Objects • Tedious to write boilerplate IEquatable<T> implementation code by hand every time • If immutable, how do we modify one? – Not entirely a trick question • If no identity, how do we persist them? ? – Deconstruction into basic data types?

Exploring Value Objects in Code

Exploring Value Objects in Code

Repositories

Repositories

Coding DDD Repositories Distilled • Domain Model not tied to specific Persistence • Abstract

Coding DDD Repositories Distilled • Domain Model not tied to specific Persistence • Abstract the act of query/retrieval • Do so in a Domain-Centric Way – (Customer. Repository. Get. By. Id(int id) is NOT domain-centric!) • This is a data-access-layer suffixed with ’Repository’!

Challenges with DDD Repositories • If no persistence in the Domain Model, how do

Challenges with DDD Repositories • If no persistence in the Domain Model, how do we reference repositories in there? – Abstraction/indirection • Repository Boundary blurring – OK for query constructs to come from outside? • repos. Get. By. Specification(Specification spec); – OK for Specification to be tied to implementation? • repos. Get. By. Criteria(Detached. Criteria crit); – OK for lazy-executed queries to be returned? • public IQueryable<Customer> Get. Customers() • Guarding against Repository API-bloat – The repository is dead, long live the repository!

Exploring Repositories in Code

Exploring Repositories in Code

Services

Services

Coding DDD Services Distilled • Actions/Behaviors not belonging in Entities • Injected into Entities

Coding DDD Services Distilled • Actions/Behaviors not belonging in Entities • Injected into Entities (? ) • Operating Autonomously from Entities

Challenges with DDD Services • Is having Services just to inject into Entities an

Challenges with DDD Services • Is having Services just to inject into Entities an anti-pattern? Order order = new Order(taxservice); double cost = Order. Total. With. Tax(); • If Services coordinate Entity interaction, who news-up the service? • Having all behavior expressed in Services and none in Entities is an anti-pattern – Or is it? And why?

Exploring Services in Code

Exploring Services in Code

Validation

Validation

Coding DDD Validation Distilled • Validation is often a stand-in for ‘business rules’ –

Coding DDD Validation Distilled • Validation is often a stand-in for ‘business rules’ – bool Can. Ship. Order(); • Distinguish between persistence validation and business action validation – Rarely the same thing! • Entity Validation – Entities can be valid for some things and invalid for others • Place an order (if valid customer w/ a valid account) • Ship an Order (if valid account and under credit limit) • Value Object Validation – Prevent VO from entering an invalid state in the first place!

Challenges with DDD Validation • Validation without ‘for what? ’ is pointless – bool

Challenges with DDD Validation • Validation without ‘for what? ’ is pointless – bool Is. Valid(); //? ? ? • Validation Frameworks tend to assume validation means persistence – Does NOT mean cannot be repurposed for Domain Validation! • Where does validation happen if it requires collaboration between multiple Entities? – bool order. Can. Ship. To(customer); – bool customer. Can. Ship(order); – bool shipping. Validator. Can. Ship(customer, order) – Anemic Domain Model Anti-Pattern?

Exploring Validation in Code

Exploring Validation in Code

Discussion • • Viewpoints Experiences Values More Discussion: – http: //www. domaindesign. org –

Discussion • • Viewpoints Experiences Values More Discussion: – http: //www. domaindesign. org – http: //tech. groups. yahoo. com/group/ Domaindrivendesign/