1 / 20

Introduction to Domain Driven Design

Introduction to Domain Driven Design. Sean Chambers. About Sean Chambers. Senior Developer at Flagler County Schools Owner Hybrid Software, Educational Software Contributor to various open source projects (Castle Project, Nhibernate, NUnit, NBehave) Practicing TDD,DDD,BDD for 2 years

genevieve
Download Presentation

Introduction to Domain Driven Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Introduction toDomain Driven Design Sean Chambers

  2. About Sean Chambers • Senior Developer at Flagler County Schools • Owner Hybrid Software, Educational Software • Contributor to various open source projects (Castle Project, Nhibernate, NUnit, NBehave) • Practicing TDD,DDD,BDD for 2 years • Blog: http://schambers.lostechies.com • Twitter: schambers

  3. 10,000 ft. view

  4. Common Architecture

  5. Where does DDD come from? Domain Driven DesignEric Evans Applying DDD and PatternsJimmy Nilsson

  6. Core Concepts • Domain Model • Ubiquitous Language • Entities • Value Objects • Repositories • Services • Aggregate Roots • Supple Design • TDD • Framework Tools

  7. Domain Model • Ditch the Database Driven Design! • OOP Models == Rich Domain Models • Driven by TDD/BDD and Refactoring • Evolves over time/after breakthroughs • NOONE gets it right the first time

  8. The Ubiquitous Language • A shared language used by developers and stakeholders alike • Translation plus risk of misunderstanding is too high of a cost • Use the model as the backbone of the language • Changes to the language, should cause a refactoring to code

  9. Entities (reference objects) • Entities are objects that contain a specific identity in your domain • Long lasting and non-transient, thus need to be persisted to a database for later retrieval • .Equals overload will compare unqiue properties • Contains all logic pertaining to state and all relevant domain logic • Beware anemic domain anti-pattern • No persistence logic!

  10. Value Objects • Value objects are defined by their attributes instead of their identity • Should be immutable, and no identity within domain • Make value objects whole classes that describe simpler Entity classes

  11. Domain Factories • Manages the creation of complex objects in the domain • Client calls Factory, factory then encapsulates complex creation of object and returns • Used for the beginning of an objects lifecycle

  12. Repositories • For each class/aggregate root setup a Repository for in-memory access • Provide add/remove methods for managing persistent objects • Repositories can be DB, XML, Flat file etc.. • Manages the middle and end of an objects lifecycle

  13. Aggregate Roots • Defines explicit boundaries within the domain where complex interaction can be placed behind • Aggregates can only speak/reference with other aggregates • Transient references for single operations only • Simplifies management of complex object graphs

  14. Address Student CourseReg Account Registration Payment Course Location Schedule

  15. Supple Design • Intention Revealing Interfaces • Student.IsRegisteredIn(course) • Registration.PaymentMethodUsed(creditPayment) • Side Effect Free Functions • Command functions • Modification and return functions • Assertions, AKA Design By Contract • Conceptual Contours • Pre-existing areas that aggregates, functions should align • Stand alone classes

  16. TDD • Very important for refactoring support • Makes you a better programmer! • Serves as model documentation for other developers • Promotes loose coupling

  17. Refactoring • Initiation • Timing • Makes the model more flexible

  18. DDD Framework Tools • Caste MonoRail/ASP.NET MVC • NHibernate, Entity Framework, O/R Mappers • Castle Windsor/Spring.NET for DI/IoC • Log4Net/NLog • TeamCity for CI • Nant/MsBuild

  19. Domain Patterns • Strategy Pattern • Encapsulate domain processes • Composite Pattern • Make whole/part domain concepts interchangable • Specification Pattern • Encapsulate specifications within objects for algorithms

  20. Questions?

More Related