domain nosql: next generation domain modelling

Next Generation Domain Modeling

tekx

Domain NoSQL

Matthew Weier O'PhinneyProject Lead, Zend Framework

The typical
first steps in PHP

design the schema

(http://musicbrainz.org/)

Been working on a new design for 6 months.

Host of new features that old did not have.

Look and feel have been reinvented

New concepts in place like member directory, online calendar, online map both using tech from Google

Info more easily updated

Special pags - Committee pages, ministry pages, youth pages, missions pages

Home page that gives quick access to current news, information, and links

Archives section to store video, audio, documents, images that can be searched

Members area for sensitive information

Possible Email Newsletter & Photo slideshows

take input, and shove it in a DB












write queries to pull from the DB


$result = mysql_query(
"SELECT * FROM sometable"
);$rows = false;if (mysql_num_rows($result) > 0) { $rows = array(); while ($row = mysql_fetch_assoc($result)) { $rows[] = $row; }}











spit data onto a page

(http://www.irs.gov/)











profit!

and watch the app get hacked with SQL injections

or watch the app grind to a halt under expensive queries

usually both











Next steps in
PHP development

design the schema












use ActiveRecord

$user = new User();$user->name = 'matthew';$user->email = '[email protected]';$user->save();

$users = User::find(array(
$id1, $id2, $id3
));























profit!

most SQL injection vectors are gone, but you've got new, expensive queries to deal with

you're really just abstracting the original problems











evolve

Use Domain Driven Design (DDD), or Behavior Driven Design (BDD)










Newsletter

Develop your application logic first, in order to determine what needs to be persisted.

the primary rule










Newsletter

define your application entities










Newsletter

implement them in code

use Zend\Session\SessionManager, Zend\Session\Configuration\StandardConfiguration, Zend\Session\Storage\SessionStorage, Zend\Session\Container;

$manager = new SessionManager();$manager->setConfig(new StandardConfiguration()) ->setStorage(new SessionStorage());

$container = new Container('auth', $manager);










Newsletter

test! (better: test first!)










Newsletter

map entities to data store

public function fromArray(array $data){ $filter = new OptionsFilter(); foreach ($data as $key => $value) { $method = 'set' . $filter($key); if (method_exists($this, $method)) { $this->$method($value); } }}

public function toArray(){ return array( '_id' => $this->getId(), 'timestamp' => $this->getTimestamp(), 'title' => $this->getTitle(),










Newsletter













profit!

sit back, enjoy a beverage, and relax!

or start building those next, great features of your application.











Rules of
Domain Logic

use Plain Old PHP Objects

class User{ public function getId() {} public function setId($value) {} public function getRealname() {} public function setRealname($value) {} public function getEmail() {} public function setEmail($value) {}}











use 3rd party code via composition

use Zend\Validator\ValidationChain;class Entry{ public function setValidator(ValidationChain $chain) { $this->_validator = $chain; return $this; }

public function fromArray(array $data) { if (!$this->getValidator()->isValid($data)) { throw new \Exception('Invalid data!'); } // ... }}











Define a schema based on
the objects you use












use mappers or transaction scripts
to translate objects to data & back

$user = new User();$user->setId('matthew') ->setName("Matthew Weier O'Phinney");$mapper->save($user);

$user = $repository->find('matthew');











use service objects
to manipulate entities

namespace Blog\Service;class Entries{ public function fetchEntry($permalink) {} public function fetchCommentCount(
$permalink) {} public function fetchComments($permalink) {} public function fetchTrackbacks($permalink) {} public function addComment($permalink,
array $comment) {} public function addTrackback($permalink,
array $comment) {} public function fetchTagCloud() {}}











What does NoSQL have to do with it?

you have a choice

Before, relational databases were the only choice










Newsletter

you have a choice

Today, relational databases are only one choice










Newsletter

defining by what it isn't?

still defining by what it isn't

types: key/value stores

each record is a key/value pair, (though the value may be non-scalar)










Newsletter

types: document databases

Each document can define its own structure

Typically a document consists of many key/value pairs

{ _id: "weierophinney", realname: "Matthew Weier O'Phinney", email: "[email protected]", roles: [ "admin", "user" ]}










Newsletter

document dbs are plentiful










Newsletter

document dbs solve
web content problems

Free yourself from the problems caused by Entity-Attribute-Value tables; store metadata where it belongs, with the document!

Allow different but related content types to co-exist in the same general storage.

Aggregate related content in the document that owns it
(e.g., tags, comments, etc.)










Newsletter

considerations with
domain models

Most Document Storage supports either JSON or arrays

Most support specifying either an ID or using a UUID

Disk usage (think: metadata describing each document)

Do you need a mapper?










Newsletter

Examples

fetch by ID with domain objects

use Blog\Entity\Entry;

$entry = new Entry();$entry->setTitle('NoSQL and Domain Objects');// implicitly sets ID to
// "nosql-and-domain-objects"

$mapper->save($entry);

$entry = $repository->find(
'nosql-and-domain-objects');










Newsletter

RDBMS schema










Newsletter

inserting an entry with couchdb

{ title: "Domain NoSQL", author: "matthew", tags: ["tekx", "nosql", "ddd"]}










Newsletter

inserting an entry with mongodb

$collection->save(array( 'title' => 'Domain NoSQL', 'author' => 'matthew', 'tags' => array( 'tekx', 'nosql', 'ddd' ),));










Newsletter

fetching by ID with couchdb

$response = $client->get( 'http://localhost:5984/blog/no-sql-and-domain-objects');$json = $response->getBody();$entry = json_decode($json);










Newsletter

fetching by ID with mongodb

$mongo = new Mongo();$db = $mongo->selectDB('blog');$entries = $db->selectCollection('entries');$entry = $entries->find(
'nosql-and-domain-objects');










Newsletter

tags in domain objects

class Entry{ public function setTags(array $tags) { foreach ($tags as $tag) { $this->addTag($tag); } }

public function addTag($tag) { $this->_tags[] = (string) $tag; }}










Newsletter

querying by tag with couchdb

/* Define a view */{ "_id": "_design/blog", "views": { "byTag": { "map": "function(doc) { if (!doc.tags) { return; } doc.tags.forEach(function(tag) { emit(tag, doc); }); }" } }}/* retrieve: /blog/_design/blog/_view/byTag?key="tagname" */










Newsletter

querying by tag with mongodb

$tagged = $entries->find(array(
'tag' => 'sometag'
));










Newsletter

Closing Notes

Don't start your development from the wrong end. Start with objects.

Be aware of all the options you have for persisting data; choose appropriately.

Consider document data stores when your objects represent content; store metadata in the document.










Newsletter

Thank you

Feedback? http://joind.in/1581http://twitter.com/weierophinneyhttp://framework.zend.com/

domain nosql: next generation domain modelling

Technology