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
- "if i give you this object, you don't have to take care if it is valid and contains consistence data"
- "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
- for the example, create email class
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.