Skip to content

FrOSCon - Unbreakable Domain Models

Mathias Varreas Mathias is helping teams escaping from survival mode. Cofounder of DDDBE Domain driven design Introduces me with a great upcomming term called "modelstorm". He also told me that a friend of him is writing on a paper about "modelstorm" so i'm looking forward to find more informations about that term on the web.

What Is This Talk About

  • Where to put business logic?
  • How to protect our code from abuse?
  • Where to put queries, and how test them?

Defining Terms

  • Domain is a problem space (let customers buy more)
  • Domain model is solution space

Domain Model

  • contains data model - the models state
  • protect your invariants (example: a customer must always have a email address)
    • create unittest with something like assertTrue($customer->hasValidEmail())
  • a less to abuse model is harder to break
    • like adding it to the constructor
  • use objects as consistency boundaries
    • "if i give you this object, you don't have to take care if it is valid and contains consistence data"
  • make the implicit the explicit
    • "a user must have a valid email address"
    • keep in mind, if you can add an "and" to describe a method, the method is doing to much
  • do not violate single responsibility principle
    • for the example, create email class
  • try to encapsulate state and behavior with (simple) value objects

Customer business process is: "A customer orders products and pays for them.".

  • try to encapsulate operations

  • use objects as consistency boundaries
    • "if i give you this object, you don't have to take care if it is valid and contains consistence data"
  • make the implicit the explicit
    • "a user must have a valid email address"
    • keep in mind, if you can add an "and" to describe a method, the method is doing to much
  • do not violate single responsibility principle
    • for the example, create email class
  • try to encapsulate state and behavior with (simple) value objects
  • Customer business process is: "A customer orders products and pays for them.".

    • try to encapsulate operations

    Customer business process is: "Order three times to become a premium member.".

    • try to create specification

      !php CustomerIsPremium::public function isSatisfiedBy(Customer $customer)

    Customer business process is: "Different rules apply for different tenants.".

    • use specifications to encapsulate rules about object selection

    Customer business process is: "Get a list of all premium customers.".

    • for big collections, try to duplicate the logic in the database (even if it breaks the single response philosophy)
    • test it by comparing (different implementation) object model code with database logic code in the unittest

    How To Persit A Model

    • implemented by a storage manager
    • special or generic storage manager has a save/add and delete/remove method

    Modelstorm

    The idea behind modelstorm (if i get it correctly) can be told as "a room of people, a bunch of magic markers, an area where you can write on". Prepare a wall with white papers. Each person can have an own marker with its own color. Each person is allowed to write on the paper. Then you start writing/creating the models. Add lines with actions to display process that handles different domain stages.