artodeto's blog about coding, politics and the world

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

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.