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.