Domain Driven Design for Mere Mortals

Domain Driven Design for Mere Mortals

Application architecture can seem like a buzzword. In this talk we will look at some useful, fundamental concepts introduced by the book on Domain Driven Design and how we as PHP developers can apply these techniques to our applications. Walking out of this talk you should have a functional understanding of how to approach designing how your applications execute business logic using DDD patterns and processes.

0f930e13633535c1c4041e95b8881308?s=128

Jeff Carouth

April 25, 2014
Tweet

Transcript

  1. PRESENTED BY JEFF CAROUTH @jcarouth Domain Driven Design for mere

    mortals
  2. What is Domain Driven Design?

  3. What is Domain Driven Design? A collection of patterns and

    principles which help developers craft elegant software.
  4. disclaimer #1 Domain Driven Design was created to solve complicated

    problems. As such there is no way to learn it in one hour, one talk, or one deep thought.
  5. Disclaimer #2 There are a lot of very complicated domains

    which would be served well by using DDD. There are many more that would not.
  6. The three important bits

  7. The three important bits 1. The Ubiquitous Language

  8. The three important bits 1. The Ubiquitous Language 2. Contexts

    and Bounded Contexts
  9. The three important bits 1. The Ubiquitous Language 2. Contexts

    and Bounded Contexts 3. Modeling
  10. The Ubiquitous Language

  11. The Ubiquitous Language A common language shared between business and

    developers which is understood to mean the same things, and, more importantly, is framed in business terminology rather than technical terminology.
  12. The Ubiquitous Language is developed over time, during discussions between

    developers and domain experts.
  13. The Ubiquitous Language consists of mainly words and expressions that

    are understood by both business experts and developers.
  14. The Ubiquitous language is expressed in the code that implements

    the domain.
  15. The Ubiquitous Language should be under constant refinement.

  16. Contexts and Bounded Contexts

  17. Context The term Context is a general description of a

    grouping of concepts.
  18. bounded context A Bounded Context is an area of your

    application that is bounded by explicit boundaries and has its own Model and maintains its own code.
  19. Context Maps Bounded Context must sometimes communicate with each other.

    A Context Map is the contract your Bounded Context agrees to fulfill with the outside world.
  20. Modeling

  21. Building Blocks

  22. Building Blocks • Entities

  23. Building Blocks • Entities • Value Objects

  24. Building Blocks • Entities • Value Objects • Aggregates

  25. Building Blocks • Entities • Value Objects • Aggregates •

    Repositories
  26. Entities An object that is uniquely identified by an identifier

    or combination of its attributes.
  27. class BankAccount! {! private $accountNumber;! private $routingNumber;! private $customerName;! private

    $customerEmail;! ! public function setAccountNumber($number)! {! $this->accountNumber = $number;! }! ! public function setRoutingNumber($number)! {! $this->accountNumber = $number;! }! }!
  28. class AccountNumber! {! public function construct($routingNumber, $accountNumber)! {! //...snip...! }!

    }! ! class BankAccount! {! private $accountNumber;! private $customer;! ! public function __construct(AccountNumber $accountNumber, ! Customer $customer)! {! $this->accountNumber = $accountNumber;! $this->customer = $customer;! }! }
  29. Value Objects An object that holds value within its state,

    but is indistinguishable from other objects of the same type with the same attributes.
  30. class Money! {! public function __construct($value, $currency)! {! //...snip...! }!

    }! ! $fiveDollars = new Money(5, 'USD');! $anotherFiveDollars = new Money(5, 'USD');
  31. class Customer! {! public function __construct($billingAddress, $email)! {! $this->billingAddress =

    $billingAddress;! $this->email = $email;! }! }
  32. class Customer! {! public function __construct($billingAddress, $email)! {! if (!/*

    nasty email regex here*/) {! throw new \InvalidArgumentException('message');! }! }! }!
  33. class Email! {! public function __construct($name)! {! if (!/* nasty

    email regex here*/) {! throw new \InvalidArgumentException('message');! }! $this->email = $email;! }! }! ! class Customer! {! public function __construct($billingAddress, Email $email)! {! $this->billingAddress = $billingAddress;! $this->email = $email;! }! }
  34. Aggregates A group of Entities and/or Value Objects which represent

    a single object or idea.
  35. class Order! {! /** @var string */! private $orderId;! !

    /** @var Customer */! private $customer;! ! /** @var Product */! private $product;! ! /** @var PaymentStatus */! private $paymentStatus;! ! /** @var OrderLines[] */! private $lineItems;! }
  36. Repositories An abstraction for persistence. A Repository can be thought

    of as an interface representing an in-memory data store for Entities or Aggregates.
  37. interface CustomerRepository! {! public function add(Customer $customer);! ! public function

    remove(Customer $customer);! ! /** @return Customer */! public function find(CustomerId $customerId);! ! /** @return array */! public function findAll();! }
  38. class DbCustomerRepository implements CustomerRepository! {! public function add(Customer $customer)! {!

    $sql = "INSERT INTO customers VALUES(...)";! //...snip...! }! }
  39. Recap

  40. Recap • DDD is a set of patterns and practices

    which help deal with business complexity in the Domain.
  41. Recap • DDD is a set of patterns and practices

    which help deal with business complexity in the Domain. • DDD is not necessarily the right fit for every project.
  42. Recap • DDD is a set of patterns and practices

    which help deal with business complexity in the Domain. • DDD is not necessarily the right fit for every project. • DDD wants you to think in Contexts.
  43. Recap • DDD is a set of patterns and practices

    which help deal with business complexity in the Domain. • DDD is not necessarily the right fit for every project. • DDD wants you to think in Contexts. • DDD has building blocks that help with the implementation of your Domain Model.
  44. Resources Domain Driven Design by Eric Evans is the original,

    more academic look into DDD. Implementing Domain Driven Design by Vaughn Vernon has a more practical approach to teaching DDD.
  45. DDDinPHP Google Group Resources The Dev Book Club is reading

    and discussing the IDDD book. Discussion group focusing on applying DDD to PHP projects. devbookclub.org dddinphp.org
  46. Thank You @jcarouth joind.in/10804