NICHOLAS HENRY: Good morning.

How many of you have read or heard of the
book,

Drawing on the Right Side of the Brain?

OK. We've got a, we've got a few people.

All right. Excellent.

For those who don't know, this book was authored

by Betty Edwards. It was originally published
in 1979,

and this latest edition was published in 1999.
And

it dispelled this myth that drawing was a
talent

that you were born with. And it's actually
a

skill that can be learned.

Now, one of these skills is viewing negative
space.

The idea that you draw the ob- you don't

draw the object, but you draw the spaces in

between the object. And this tricks the brain.
It

switches the brain from a left mode to a

logical think- from a logical thinking mode
to a

right-brain or a perceptual mode.

And the benefit of this is when we're making

logical decisions, but we make bad perceptual
decisions. Great

example is this chair. If you look at the

chair, you'll see the legs are quite thin.
And

logically you think, man, if I sit on that

chair, that's not gonna hold. That's not gonna
support

a person. And so logically would go, would
increase

the size of those legs, and we end up

distorting the, the picture.

Betty Edwards describes drawing as five, sorry,
she describes

drawing as a global skill, consisting of five
basic

skills. And she describes these skills as
perceptual skills.

The ability to correctly and efficiently understand
what is

being seen.

I'm Nicholas Henry, and I'd like to welcome
you

to my talk, Modeling on the Right Side of

the Brain, where I'll introduce you to the
five

basic skills of object-modeling. We will explore
using color

and patterns to help you visualize and communicate
and

understand the main models.

And the five basic skills for object-modeling
are finding

objects, identifying collaborations, defining
business rules, and assigning services

and attributes.

So I just want to make sure we're all

on the same page, in, in terms of what

a domain model is. So we're just gonna review

the scenario of shipping an order, which would
behest

be an economist domain.

Now, a domain really represents a business
process. So

let's go through, through this example. So
we have

a business request that comes into our domain.
In

this case it's to ship an order. An order

which represents a business object will receive
this, and

it will go ahead and create a shipment. Another

business object that it'll collaborate with.

But we probably want to make sure that order's

been paid for before we ship that order. It

probably wouldn't make much sense, business
sense, right. So

we have a business role that will check that

that order's actually been paid for.

So, essentially, a business domain, or a domain
model,

is a set of business objects that represent
these

real-world entities. There are collaborations,
there are business rules,

and there are services that respond to business
requests.

Now, a model is simply a representation of
something.

It could be a mental model, our mental understanding

of how a business process works. It might
be

a graphical notation or, sorry, a graphical
model such

as a notation that I'm using up here. Or

it might even be codified in your models directory

in your Rails application.

Of course, there are other concerns when you're
building

an application. These things like persisting
those business objects

to a database, generating HTML or JSON, or
even

handling that HTTP request that comes into
your controller.

But these are things that are outside of your

domain model. And you can, can think of the

domain model as the heart of your application.

So I use this term business services when
a

business request comes in, we'll use a business
service

to respond to that request. Now, this is where

the services that you might have heard in
the

previous talk on domain-driven design, and
it's a pattern

that Rails developers have developed over
the last couple

of years, where we create a service class
to

encapsulate logic such as, sort of, sending
out an

email or finding, finding a user record.

And the idea is to kind of thin down

the responsibilities of the controller. When
I use the

term service, I'm not referring to that. I'm
referring

to this idea of responding to a business request.

I'll try to use the, the term business service

to differentiate from this idea of a service
class.

So why, why object modeling? Well, it feels
like

there's a gap between user stories. You know,
user

stories are great at requirements gathering.
They're great for

describing business requests at, from the
end user's perspective.

But how do we take those requirements and
then

go ahead and implement that model in our Rails

application?

It's almost like we're missing a tool. We're
missing

a tool to represent this underlying business
model. A

tool to identify the business objects that
represent these

real-world entities. A tool to define the
define rules

that govern these collaborations.

I think as Rails developers, we kind of lack

a language, in terms of talking about domains.
Normally,

we talk about domains in the form of associations

and has_many and belongs_to.

Object modeling is a practice, and these five
basic

skills will help us bridge this gap between
user

stories and implementation. Now, I just want
to be

clear in terms of setting expectations for
this talk.

I'm not gonna be showing any code. OK. Great.

No one got up and left. That's a good

sign.

And, so there's gonna be no code examples.
And

there'll be lots of talks that are, over the

next couple of days, you know, showing different
implementations.

And the thing is with this, with this practice

of object modeling, I believe it's independent
of implementation.

It just helps you understand the business
model itself.

Now, this idea of, this practice of object
modeling,

it's not new. And Peter Coad first discussed
this

in his book, Java Modeling in Color with UML.

This was first published in 1999. And, this
is

not gonna be a popular book for Rubyists,
right.

It has two things going wrong with it. It

has Java and UML in the title.

But there were some other books that were
published

around the time, and other ones such as Streamlined

Object Modeling by Jill Nicola. And this really
influenced

my thinking in terms of how to understand
a

business domain.

And what I like about object modeling is that

it provides us a framework. Very much like
Rails

provides us a framework in terms of providing
us

guidance in terms of structuring our application.
It provides

us conventions. And it helps us accelerate
our web

development.

And object modeling's a little like that.
It allows

us to discuss, visualize, and help us, guide
us

in terms of implementing those domains. But
it also,

it helps us to accelerate our understanding
of those

business domains.

Now, I'm not advocating any big upfront design.
This

is simply a tool to sketch out those ideas,

to collaborate with your team members and
help guide

your implementation. Sure, the diagrams that
I'm going to

be using today are URML, UML, the unified
modeling

language. But these are simply communication
tools. The goal

is not the diagrams themselves.

Now as object modelers, our basic building
blocks are

objects. Which is fantastic, cause as Rubyists,
we work

in a object-oriented language. Now, when I
speak about

objects, I'm going to speak in the first person.

And this helps us personify these objects.

So objects have three responsibilities. Who
I know, what

I do, and what I know.

An example of that, coming back to an order,

an order would know a number, it would know

its state - if it's paid. It would know

a timestamp for when it was purchased at.
Of

course, it knows other collaborators. So it
knows a

shipment and it knows how to ship itself:
its

business service.

So now that we have this building block, let's

look at finding objects, our first skill.

The problem with finding objects is that often
we

look at business objects as unique. They're
these pretty

little snow flakes. But in effect, we can
group

objects with more or less the same responsibilities
of

what, who I know, what I do, and what

I know.

And these groups are known as archetypes,
the term

that Peter Coad assigned to this. And we have

four archetypes. We have an event, a role,
a

party, place, or thing, or a description.
Party, place,

or thing's a little bit of a mouthful to

say every time, so we'll refer to these as

the PPTs.

So let's look at our first archetype. Our
first

archetype are events. And these are modeled
as transactions

within our domain. They're the most important
business objects.

They're the glue for all the other objects
in

our business domain. And without an event,
I would

assert the application is simply a catalog
application.

So we've got some examples up here. So in

the, in the domain of the ecommerce we would

have an order and a shipment. These are transactions

within that domain. If we're modeling a hotel
reservation

system or a car reservation, we'd have a reservation

event.

And we have two types of events. We have

a point in time and an interval. So a

point in time has a single timestamp, such
as

order, with the purchased_at date. And then
we have

reservation. A reserv- sorry. We have an internal
archetype,

illustrated by the reservation here.

And this is timestamped, or bookend by two
timestamps.

So the checkin_at date and the checkout.

Now, roles don't live in isolation. They,
they're the

glue in the domain. And other objects interact
in

this event. And we use roles to represent
the

way an object participates in this event.
So as

an example, we have a customer and a sales

agent that would interact with an order. And
a

fulfillment provider that would interact with
the shipment.

So if we have roles, then we need actors.

And the actors in our domain, as, are these,

is the PPTs. Now, so, a party would be

a person or an organization. The place would
be,

such of a thing as a warehouse if we

were doing shipment. And everything else is
a thing.

So, again, an example here is the, is the

product.

And our final archetype is a description.
And descriptions

are responsible for describing a collection
of similar objects,

such as our PPTs. An example of this would

be a product category that would describe
a, a

collection of products. A collection of things
such as

t-shirts. Or a collection of jeans on an ecommerce

site.

Now, the concept of a description object can
be

a little tough to kind of grasp sometimes.
So

I'll talk about this in a little bit more

detail when we talk about identifying collaborations.

Now, when we're collaborating or presenting
a diagram visually,

as soon as we have a few business objects

on a, on a diagram, it becomes a little

tough to navigate. Don't worry, you're not
supposed to

be able to read all the details here. I'm

just gonna illustrate something.

But we can solve this issue in, in terms

of navigating these diagrams. We can add color,
to

give another layer of information. Did anyone
notice the

slides change color when I was talking about
the

archetypes? Anyone paying notice? Oh, one
person. What, what,

what color was event?

Sorry?

AUDIENCE: Yellow.

N.H.: Yellow? Almost. It was the role. But,
the

event was the pink or the red. And pink's

a great color for an event, cause it highlights

sensitivity in the domain model. It's this
hot spot.

We'll use yellow for roles. The green for
the

PPTs. And the blue for the description.

So we can take a visualization of this in

terms of our domain model and add color to

that, and you can immediately see this hotspot
within

your domain model.

You can see the events and you can see

the other objects interacting with those events
through the

yellow roles.

Now, more importantly, we have this awesome
collaboration tool

where we can use post-it notes that correspond
to

these colored archetypes, and a white board,
and with

our team members we can collaborate in an
agile

manner into, on our business domain.

So now we have these four archetypes that
helps

us guide finding business objects in our domain.
But

you might have found, might have noticed that
it

was a little difficult for me to talk about

one object in isolation. And this leads us
to

our next skill, identifying collaborations.

Before moving onto collaborations, I just
wanted to discuss

this idea of associations versus collaborations.
As Rails developers,

we're very familiar with the idea of associations,
from,

from ActiveRecord. But associations kind of
have this idea

of a passive relationship, where collaborations
kind of communicates

this idea of an active relationship with dialogue.

And dialogue becomes very important when we
talk about

business rules. So I'm gonna use the idea
of

collaborations for the rest of this talk.

Now, identifying collaborations addresses
this object's responsibility of who

I know. Now, often we think about objects
in

isolation. We think about a customer. We think
about

an order. But the presence of one business
object

suggests the presence of another.

And this is really highlighted by this, what
I've

dubbed the elementary collaboration pattern.
So let's walk through

this. So when we have the presence of an

event, we know that that, there's a role required

to interact with that event. And if we have

roles, we need an actor. And this is our

PPTs. And, of course, if we have a collection

of PPTs, perhaps we need a description to
describe

that collection.

Now, this is essentially a template. And templates
are

meant to be modified based on need. An example

of this, if you have a PPT that only

participates in one event, do not create a
dedicated

role for that. That's just going to complicate
your

object model.

Here we have an example of a person interacting

with order. So a person can either interact
with

that as a customer or as a sales agent.

So, of course, the customer is the one who

is purchasing that order, and the other is
the,

perhaps, approving that order.

Now, we might have a business role that suggests

that we, the same person cannot be the same,

sorry, the same person cannot play the roles
at

the same time. Meaning they can't be the customer

and the sales agent.

There's another notation that I've introduced
here, in terms

of the UML, is that we have multiplicity rules

identified. So the one next to the customer
on

the right-hand side suggests that there's
a, an order

only belongs to one customer. And a customer
can

actually belong to many orders, and that's
denoted by

the zero and the asterisks next to the order.

Now, here's a description of the PPTs, sorry,
a

PPT versus a description. I was talking about
how

descriptions might be a little bit tough to
grasp.

We're just gonna go through an example here.

Here, we have a vehicle that's uniquely identified
by

a registration number. And we have a vehicle
make

that describes that vehicle. It describes
the model and

it describes the year that model was released.

Let's take a little concrete example and we'll
make

this a little clearer. So here we have four

instances of, of a vehicle. We have one and

two, and you'll see that there's a uniquely
identified

registration number. But we have duplicated
data here, sorry,

duplicated attributes here, with the model
and year.

And this is repeated again in the instances
three

and four. I've highlighted it here so you
can

see the, the repeating data.

And we can, of course, extract them. We'll
use

a business, business, request kind of term
business service

when we can extract those repeating attributes.

(weird audio - (00:17:45)

And here business object in the, with the
registration

number is our vehicle, and with the model
and

year we have the vehicle make. So the instances

of one and two of the vehicle are described

by the first instance of the description,
which is

the Corolla 2010. And the rows three, sorry,
the

instances three and four are described by
the second

instance of that description, the Focus 2014.

So you can sort of think about this in

the terms of data normalization.

Now, archetypes can collaborate with the same
archetype. So

a PPT can collaborate with another PPT. In
this

instance we're gonna look at event collaborations.
And there's

two event collaborations that we'll have a
look at.

The first one is the composite. The composite
is

actually made up of other events.

So here we have the, the composite transaction
and

the line item. The example is the order and

the order line item. I've introduced another
little bit

of UML notation with that solid, the solid
diamond,

and that denotes the composite within this
pattern.

Another event collaboration pattern is the
follow-up pattern, where

we have a transaction and then we have a

follow-up transaction. And in this case we
have an

order that is followed up by a shipment. Another

example of this would be an order followed
up

by a payment.

So let's sort of take a look at this

in a, in an example, a larger example. Here

we have a, a product description describing
a collection

of products. This product is interacting with
this order

line item. And this is kind of a, this,

this product interacting with a, a order line
item,

the idea of the thing interacting with a,
with

a line item. That's a common pattern that
you'll

see in, in domains.

But the interesting thing here is the, is
the

composite. And that, the highlighting's not
showing up very

well. I apologize for that.

But the order and the order line item is

our composite pattern that we've seen before.
The interesting

thing is, we repeat this pattern as well.
So

with a shipment and a shipment line item,
there

is a comp, a composite.

And we can repeat this again in terms of

the order line, sorry, the shipment line item
is

a follow-up for the order-line item. But this
is

when the magic starts to happen, is when we

had another composite with a return and return
line-item.

And again, and this is a collaboration, a
composite

collaboration.

And we can use these, these collaboration
patterns as

a building block in our domains as well.

And this moves us on to business rules. So,

you know, so we're talking about these collaborations,
but

what governs these collaborations. So business
rules are either

policies that specify how a business should
operate, or

these are constraints that are forced upon
a business,

such as laws determined by a government.

Now often when we think about business rules,
we

kind of think about validation roles, where
we're just

validation that an email is present, or if
it's

in the correct format such as using a regular

expression for that email address. But business
rules extend

beyond this.

They govern, or validate, collaborations.

Now, if business rules govern collaborations,
then each partner,

that business object, must determine if that
collaboration is

valid. Because each partner may have a different
condition

to determine if that is a valid collaboration.

Here we have an example of a shipment and

a shipping method that are looking to collaborate.
The

shipment has a total weight, and it might
be

expedited. So we want to get that shipment
out

quickly.

A shipping method has a, has a maximum weight

and a duration. So let's look at these two

ob, business objects collaborating.

Now, a shipping method adds a constraint on
its

collaboration with a shipment. It will not
collaborate with

a shipment whose total weight exceeds the
maximum weight.

Likewise, a shipment has a constraint on its
collaboration

with the shipping method. It will not collaborate,
sorry,

if that shipment is expedited, it will not
collaborate

with a shipment, sorry, with a shipping method
whose

duration exceeds two days.

So from this example, we've illustrated that
each partner

must validate the collaboration. And each
partner adds a

constraint, sorry, each partner adds a constraint
to that

collaboration, owns that business rule. And
that business rule's

encapsulated in that business object. And
it shields that

condition from its collaborator.

So now that we understand that business rules
are

simply not validation rules, that they govern
these collaborations,

when do these collaborations form?

And this takes us to our fourth skill or

assigning services.

And services, it's, are related to the responsibility
of

what I do. Now, business services respond
to business

requests. They form new collaborations. They
dissolve collaborations. And

they may even create new event objects. Of
course,

services can update attributes.

However, for this talk, I'm gonna focus on
collaboration.

Now, as a reminder, we'll just revisit this
scenario

from the beginning of my talk. Here, we have

a business request coming into our domain,
and that's

gonna be to ship an order. The order's going

to respond to that. But it's gonna check that

business rule to make sure it's being paid.
And

then it'll go ahead and it will create a

new shipment and collaborate with that.

So a challenge when we're object modeling
is that

in the real world, entities are acted upon.
Someone

ships an order. But when we're object modeling,
objects

that represent those real world entities perform
the actions

themselves.

So an order will ship itself. And the reason

for that is that all the information inside
an

object, sorry, all the information needed
to act on

that object is inside of that object. So let

that object do the work.

Otherwise we end up sort of creating these
dedicated

coordinating objects like shipment manager.
And an object like

shipment manager doesn't represent a real-world
entity and just

adds conceptual noise to our domain model.

So with this in mind, we assign this ship

service to the order, so it can respond to

that business request. And the service becomes
an object

factory for the shipment. And this is a pat,

and follows the pattern of services becoming
object factories

for events.

And here we come to our last skill, in

terms of assigning attributes. And we've already
taken a

look at some attributes. These attributes
respond to what

I know.

So coming back to our vehicle and our vehicle

make, a vehicle with its registration number
is a

descriptive or tacking attribute, which is
typical of a

PPT. With the vehicle make we have these two

descriptive attributes of a, of the model
and the

year.

From our order example, again, we, for the
order

it has this tracking attribute of a number.
It

knows its state and it has this time stamp

that's, that point in time events have.

Now, Jill Nicola, in her book Streamlined
Object Modeling,

has identified six types of attributes. I
won't go

through all six, but you can see some examples

on the right hand side there.

I'll focus on two attributes. The life cycle
state

and the operating state. The life cycle state
is

a, is a one-way state transition. So an order

would transition from pending to paid to complete,
but

it won't revert back to that stage.

An operating stage is a state that switches
back

and forth between two states. So an example
here

is a product could be active, so active in

a, in a catalog. We could switch that off

and it wouldn't appear, appear in the catalog
anymore.

And then we could switch it on. So it

switches back and forth.

So now that you've been introduced to the
five

basic skills of object modeling, we have a
set

of skills to bridge this gap between your
user

stories and your Rails application. You have
a framework

to explore business domains.

So, I've simply given you an introduction
here. And

if this talk has resonated with you, you're
probably

hungry for more. So I've outlined these three
steps

to help get you started.

First, I've created a dedicated blog post
providing some

online resources that, resources that you
can read today.

Plus links to the books that I talked about

in this talk.

Secondly, talk, share this with you team members.
This

idea of object modeling is awesome to use
as

an individual, but the real power is when
you

have this common language with your team mates,
and

collaborate with each other.

And then the third step is buy some post-it

notes. Post-it notes are an awesome collaboration
tool and

some, and a simple collaboration tool, and
it makes

this whole modeling fun.

So the next time, when a team member asks

you, how do I model this? Use archetypes to

guide you in finding objects. Use color to
visualize

and collaborate with your team members. Use
the presence

of one object to suggest the presence of another

and form collaborations. Use business rules
to validate or

govern these collaborations. Assign services
to business objects to

fulfill business requests. And use these skills
to build

a model that mirrors the business, enabling
you to

correctly and efficiently understand the domain.

Thank you.