0:00:16.760,0:00:20.810
NICHOLAS HENRY: Good morning.

0:00:20.810,0:00:24.119
How many of you have read or heard of the[br]book,

0:00:24.119,0:00:25.619
Drawing on the Right Side of the Brain?

0:00:25.619,0:00:28.750
OK. We've got a, we've got a few people.

0:00:28.750,0:00:30.310
All right. Excellent.

0:00:30.310,0:00:32.070
For those who don't know, this book was authored

0:00:32.070,0:00:36.730
by Betty Edwards. It was originally published[br]in 1979,

0:00:36.730,0:00:40.540
and this latest edition was published in 1999.[br]And

0:00:40.540,0:00:43.390
it dispelled this myth that drawing was a[br]talent

0:00:43.390,0:00:45.710
that you were born with. And it's actually[br]a

0:00:45.710,0:00:47.980
skill that can be learned.

0:00:47.980,0:00:52.830
Now, one of these skills is viewing negative[br]space.

0:00:52.830,0:00:55.129
The idea that you draw the ob- you don't

0:00:55.129,0:00:57.659
draw the object, but you draw the spaces in

0:00:57.659,0:01:01.210
between the object. And this tricks the brain.[br]It

0:01:01.210,0:01:03.290
switches the brain from a left mode to a

0:01:03.290,0:01:06.440
logical think- from a logical thinking mode[br]to a

0:01:06.440,0:01:09.460
right-brain or a perceptual mode.

0:01:09.460,0:01:11.750
And the benefit of this is when we're making

0:01:11.750,0:01:16.369
logical decisions, but we make bad perceptual[br]decisions. Great

0:01:16.369,0:01:18.860
example is this chair. If you look at the

0:01:18.860,0:01:21.720
chair, you'll see the legs are quite thin.[br]And

0:01:21.720,0:01:23.830
logically you think, man, if I sit on that

0:01:23.830,0:01:25.670
chair, that's not gonna hold. That's not gonna[br]support

0:01:25.670,0:01:28.940
a person. And so logically would go, would[br]increase

0:01:28.940,0:01:31.190
the size of those legs, and we end up

0:01:31.190,0:01:33.170
distorting the, the picture.

0:01:33.170,0:01:39.810
Betty Edwards describes drawing as five, sorry,[br]she describes

0:01:39.810,0:01:43.700
drawing as a global skill, consisting of five[br]basic

0:01:43.700,0:01:48.840
skills. And she describes these skills as[br]perceptual skills.

0:01:48.840,0:01:52.920
The ability to correctly and efficiently understand[br]what is

0:01:52.920,0:01:54.920
being seen.

0:01:54.920,0:01:57.140
I'm Nicholas Henry, and I'd like to welcome[br]you

0:01:57.140,0:01:59.700
to my talk, Modeling on the Right Side of

0:01:59.700,0:02:02.090
the Brain, where I'll introduce you to the[br]five

0:02:02.090,0:02:06.280
basic skills of object-modeling. We will explore[br]using color

0:02:06.280,0:02:09.619
and patterns to help you visualize and communicate[br]and

0:02:09.619,0:02:13.340
understand the main models.

0:02:13.340,0:02:16.390
And the five basic skills for object-modeling[br]are finding

0:02:16.390,0:02:23.370
objects, identifying collaborations, defining[br]business rules, and assigning services

0:02:23.370,0:02:26.030
and attributes.

0:02:26.030,0:02:27.359
So I just want to make sure we're all

0:02:27.359,0:02:29.950
on the same page, in, in terms of what

0:02:29.950,0:02:32.260
a domain model is. So we're just gonna review

0:02:32.260,0:02:35.469
the scenario of shipping an order, which would[br]behest

0:02:35.469,0:02:37.519
be an economist domain.

0:02:37.519,0:02:41.739
Now, a domain really represents a business[br]process. So

0:02:41.739,0:02:44.150
let's go through, through this example. So[br]we have

0:02:44.150,0:02:47.279
a business request that comes into our domain.[br]In

0:02:47.279,0:02:50.709
this case it's to ship an order. An order

0:02:50.709,0:02:54.739
which represents a business object will receive[br]this, and

0:02:54.739,0:02:57.639
it will go ahead and create a shipment. Another

0:02:57.639,0:03:00.290
business object that it'll collaborate with.

0:03:00.290,0:03:02.579
But we probably want to make sure that order's

0:03:02.579,0:03:04.879
been paid for before we ship that order. It

0:03:04.879,0:03:07.659
probably wouldn't make much sense, business[br]sense, right. So

0:03:07.659,0:03:10.420
we have a business role that will check that

0:03:10.420,0:03:12.719
that order's actually been paid for.

0:03:12.719,0:03:17.379
So, essentially, a business domain, or a domain[br]model,

0:03:17.379,0:03:20.900
is a set of business objects that represent[br]these

0:03:20.900,0:03:25.639
real-world entities. There are collaborations,[br]there are business rules,

0:03:25.639,0:03:29.909
and there are services that respond to business[br]requests.

0:03:29.909,0:03:33.400
Now, a model is simply a representation of[br]something.

0:03:33.400,0:03:36.359
It could be a mental model, our mental understanding

0:03:36.359,0:03:39.230
of how a business process works. It might[br]be

0:03:39.230,0:03:42.230
a graphical notation or, sorry, a graphical[br]model such

0:03:42.230,0:03:44.959
as a notation that I'm using up here. Or

0:03:44.959,0:03:47.889
it might even be codified in your models directory

0:03:47.889,0:03:49.689
in your Rails application.

0:03:49.689,0:03:53.239
Of course, there are other concerns when you're[br]building

0:03:53.239,0:03:56.389
an application. These things like persisting[br]those business objects

0:03:56.389,0:04:01.809
to a database, generating HTML or JSON, or[br]even

0:04:01.809,0:04:05.439
handling that HTTP request that comes into[br]your controller.

0:04:05.439,0:04:07.650
But these are things that are outside of your

0:04:07.650,0:04:09.859
domain model. And you can, can think of the

0:04:09.859,0:04:15.779
domain model as the heart of your application.

0:04:15.779,0:04:17.880
So I use this term business services when[br]a

0:04:17.880,0:04:21.060
business request comes in, we'll use a business[br]service

0:04:21.060,0:04:24.449
to respond to that request. Now, this is where

0:04:24.449,0:04:26.800
the services that you might have heard in[br]the

0:04:26.800,0:04:30.410
previous talk on domain-driven design, and[br]it's a pattern

0:04:30.410,0:04:33.350
that Rails developers have developed over[br]the last couple

0:04:33.350,0:04:35.670
of years, where we create a service class[br]to

0:04:35.670,0:04:38.850
encapsulate logic such as, sort of, sending[br]out an

0:04:38.850,0:04:44.070
email or finding, finding a user record.

0:04:44.070,0:04:45.500
And the idea is to kind of thin down

0:04:45.500,0:04:48.280
the responsibilities of the controller. When[br]I use the

0:04:48.280,0:04:50.760
term service, I'm not referring to that. I'm[br]referring

0:04:50.760,0:04:53.910
to this idea of responding to a business request.

0:04:53.910,0:04:56.160
I'll try to use the, the term business service

0:04:56.160,0:05:02.120
to differentiate from this idea of a service[br]class.

0:05:02.120,0:05:05.950
So why, why object modeling? Well, it feels[br]like

0:05:05.950,0:05:08.900
there's a gap between user stories. You know,[br]user

0:05:08.900,0:05:12.100
stories are great at requirements gathering.[br]They're great for

0:05:12.100,0:05:17.980
describing business requests at, from the[br]end user's perspective.

0:05:17.980,0:05:19.850
But how do we take those requirements and[br]then

0:05:19.850,0:05:22.510
go ahead and implement that model in our Rails

0:05:22.510,0:05:23.170
application?

0:05:23.170,0:05:26.940
It's almost like we're missing a tool. We're[br]missing

0:05:26.940,0:05:30.780
a tool to represent this underlying business[br]model. A

0:05:30.780,0:05:33.880
tool to identify the business objects that[br]represent these

0:05:33.880,0:05:38.380
real-world entities. A tool to define the[br]define rules

0:05:38.380,0:05:40.590
that govern these collaborations.

0:05:40.590,0:05:43.720
I think as Rails developers, we kind of lack

0:05:43.720,0:05:47.020
a language, in terms of talking about domains.[br]Normally,

0:05:47.020,0:05:49.440
we talk about domains in the form of associations

0:05:49.440,0:05:53.500
and has_many and belongs_to.

0:05:53.500,0:05:55.900
Object modeling is a practice, and these five[br]basic

0:05:55.900,0:05:58.640
skills will help us bridge this gap between[br]user

0:05:58.640,0:06:02.190
stories and implementation. Now, I just want[br]to be

0:06:02.190,0:06:05.050
clear in terms of setting expectations for[br]this talk.

0:06:05.050,0:06:08.160
I'm not gonna be showing any code. OK. Great.

0:06:08.160,0:06:10.790
No one got up and left. That's a good

0:06:10.790,0:06:11.250
sign.

0:06:11.250,0:06:13.890
And, so there's gonna be no code examples.[br]And

0:06:13.890,0:06:15.580
there'll be lots of talks that are, over the

0:06:15.580,0:06:18.610
next couple of days, you know, showing different[br]implementations.

0:06:18.610,0:06:21.230
And the thing is with this, with this practice

0:06:21.230,0:06:24.780
of object modeling, I believe it's independent[br]of implementation.

0:06:24.780,0:06:28.330
It just helps you understand the business[br]model itself.

0:06:28.330,0:06:32.380
Now, this idea of, this practice of object[br]modeling,

0:06:32.380,0:06:35.580
it's not new. And Peter Coad first discussed[br]this

0:06:35.580,0:06:39.970
in his book, Java Modeling in Color with UML.

0:06:39.970,0:06:43.010
This was first published in 1999. And, this[br]is

0:06:43.010,0:06:45.670
not gonna be a popular book for Rubyists,[br]right.

0:06:45.670,0:06:47.410
It has two things going wrong with it. It

0:06:47.410,0:06:51.340
has Java and UML in the title.

0:06:51.340,0:06:52.740
But there were some other books that were[br]published

0:06:52.740,0:06:55.020
around the time, and other ones such as Streamlined

0:06:55.020,0:06:58.430
Object Modeling by Jill Nicola. And this really[br]influenced

0:06:58.430,0:07:01.990
my thinking in terms of how to understand[br]a

0:07:01.990,0:07:04.360
business domain.

0:07:04.360,0:07:07.110
And what I like about object modeling is that

0:07:07.110,0:07:10.100
it provides us a framework. Very much like[br]Rails

0:07:10.100,0:07:13.500
provides us a framework in terms of providing[br]us

0:07:13.500,0:07:17.420
guidance in terms of structuring our application.[br]It provides

0:07:17.420,0:07:21.770
us conventions. And it helps us accelerate[br]our web

0:07:21.770,0:07:22.540
development.

0:07:22.540,0:07:24.550
And object modeling's a little like that.[br]It allows

0:07:24.550,0:07:27.930
us to discuss, visualize, and help us, guide[br]us

0:07:27.930,0:07:30.820
in terms of implementing those domains. But[br]it also,

0:07:30.820,0:07:34.580
it helps us to accelerate our understanding[br]of those

0:07:34.580,0:07:35.980
business domains.

0:07:35.980,0:07:40.370
Now, I'm not advocating any big upfront design.[br]This

0:07:40.370,0:07:44.360
is simply a tool to sketch out those ideas,

0:07:44.360,0:07:47.240
to collaborate with your team members and[br]help guide

0:07:47.240,0:07:50.730
your implementation. Sure, the diagrams that[br]I'm going to

0:07:50.730,0:07:54.480
be using today are URML, UML, the unified[br]modeling

0:07:54.480,0:07:59.330
language. But these are simply communication[br]tools. The goal

0:07:59.330,0:08:02.380
is not the diagrams themselves.

0:08:02.380,0:08:07.290
Now as object modelers, our basic building[br]blocks are

0:08:07.290,0:08:10.020
objects. Which is fantastic, cause as Rubyists,[br]we work

0:08:10.020,0:08:13.020
in a object-oriented language. Now, when I[br]speak about

0:08:13.020,0:08:16.340
objects, I'm going to speak in the first person.

0:08:16.340,0:08:20.030
And this helps us personify these objects.

0:08:20.030,0:08:26.870
So objects have three responsibilities. Who[br]I know, what

0:08:26.870,0:08:31.930
I do, and what I know.

0:08:31.930,0:08:34.019
An example of that, coming back to an order,

0:08:34.019,0:08:36.089
an order would know a number, it would know

0:08:36.089,0:08:38.360
its state - if it's paid. It would know

0:08:38.360,0:08:40.950
a timestamp for when it was purchased at.[br]Of

0:08:40.950,0:08:43.269
course, it knows other collaborators. So it[br]knows a

0:08:43.269,0:08:46.019
shipment and it knows how to ship itself:[br]its

0:08:46.019,0:08:49.060
business service.

0:08:49.060,0:08:51.110
So now that we have this building block, let's

0:08:51.110,0:08:56.050
look at finding objects, our first skill.

0:08:56.050,0:08:58.610
The problem with finding objects is that often[br]we

0:08:58.610,0:09:01.779
look at business objects as unique. They're[br]these pretty

0:09:01.779,0:09:05.020
little snow flakes. But in effect, we can[br]group

0:09:05.020,0:09:09.330
objects with more or less the same responsibilities[br]of

0:09:09.330,0:09:12.140
what, who I know, what I do, and what

0:09:12.140,0:09:13.800
I know.

0:09:13.800,0:09:16.460
And these groups are known as archetypes,[br]the term

0:09:16.460,0:09:18.550
that Peter Coad assigned to this. And we have

0:09:18.550,0:09:22.810
four archetypes. We have an event, a role,[br]a

0:09:22.810,0:09:27.160
party, place, or thing, or a description.[br]Party, place,

0:09:27.160,0:09:29.330
or thing's a little bit of a mouthful to

0:09:29.330,0:09:31.290
say every time, so we'll refer to these as

0:09:31.290,0:09:34.340
the PPTs.

0:09:34.340,0:09:37.540
So let's look at our first archetype. Our[br]first

0:09:37.540,0:09:40.540
archetype are events. And these are modeled[br]as transactions

0:09:40.540,0:09:44.710
within our domain. They're the most important[br]business objects.

0:09:44.710,0:09:47.270
They're the glue for all the other objects[br]in

0:09:47.270,0:09:51.090
our business domain. And without an event,[br]I would

0:09:51.090,0:09:55.950
assert the application is simply a catalog[br]application.

0:09:55.950,0:09:57.920
So we've got some examples up here. So in

0:09:57.920,0:09:59.620
the, in the domain of the ecommerce we would

0:09:59.620,0:10:02.440
have an order and a shipment. These are transactions

0:10:02.440,0:10:05.670
within that domain. If we're modeling a hotel[br]reservation

0:10:05.670,0:10:08.870
system or a car reservation, we'd have a reservation

0:10:08.870,0:10:11.800
event.

0:10:11.800,0:10:14.190
And we have two types of events. We have

0:10:14.190,0:10:16.870
a point in time and an interval. So a

0:10:16.870,0:10:19.420
point in time has a single timestamp, such[br]as

0:10:19.420,0:10:23.080
order, with the purchased_at date. And then[br]we have

0:10:23.080,0:10:28.870
reservation. A reserv- sorry. We have an internal[br]archetype,

0:10:28.870,0:10:31.360
illustrated by the reservation here.

0:10:31.360,0:10:34.550
And this is timestamped, or bookend by two[br]timestamps.

0:10:34.550,0:10:38.510
So the checkin_at date and the checkout.

0:10:38.510,0:10:42.450
Now, roles don't live in isolation. They,[br]they're the

0:10:42.450,0:10:45.740
glue in the domain. And other objects interact[br]in

0:10:45.740,0:10:49.610
this event. And we use roles to represent[br]the

0:10:49.610,0:10:54.440
way an object participates in this event.[br]So as

0:10:54.440,0:10:56.580
an example, we have a customer and a sales

0:10:56.580,0:10:59.330
agent that would interact with an order. And[br]a

0:10:59.330,0:11:03.820
fulfillment provider that would interact with[br]the shipment.

0:11:03.820,0:11:08.360
So if we have roles, then we need actors.

0:11:08.360,0:11:10.920
And the actors in our domain, as, are these,

0:11:10.920,0:11:15.060
is the PPTs. Now, so, a party would be

0:11:15.060,0:11:19.430
a person or an organization. The place would[br]be,

0:11:19.430,0:11:21.650
such of a thing as a warehouse if we

0:11:21.650,0:11:24.350
were doing shipment. And everything else is[br]a thing.

0:11:24.350,0:11:26.670
So, again, an example here is the, is the

0:11:26.670,0:11:27.839
product.

0:11:27.839,0:11:33.810
And our final archetype is a description.[br]And descriptions

0:11:33.810,0:11:38.600
are responsible for describing a collection[br]of similar objects,

0:11:38.600,0:11:41.380
such as our PPTs. An example of this would

0:11:41.380,0:11:44.529
be a product category that would describe[br]a, a

0:11:44.529,0:11:46.830
collection of products. A collection of things[br]such as

0:11:46.830,0:11:50.130
t-shirts. Or a collection of jeans on an ecommerce

0:11:50.130,0:11:50.740
site.

0:11:50.740,0:11:54.180
Now, the concept of a description object can[br]be

0:11:54.180,0:11:56.980
a little tough to kind of grasp sometimes.[br]So

0:11:56.980,0:11:58.430
I'll talk about this in a little bit more

0:11:58.430,0:12:02.710
detail when we talk about identifying collaborations.

0:12:02.710,0:12:08.740
Now, when we're collaborating or presenting[br]a diagram visually,

0:12:08.740,0:12:10.480
as soon as we have a few business objects

0:12:10.480,0:12:12.680
on a, on a diagram, it becomes a little

0:12:12.680,0:12:15.680
tough to navigate. Don't worry, you're not[br]supposed to

0:12:15.680,0:12:19.089
be able to read all the details here. I'm

0:12:19.089,0:12:21.350
just gonna illustrate something.

0:12:21.350,0:12:23.690
But we can solve this issue in, in terms

0:12:23.690,0:12:27.940
of navigating these diagrams. We can add color,[br]to

0:12:27.940,0:12:33.529
give another layer of information. Did anyone[br]notice the

0:12:33.529,0:12:35.700
slides change color when I was talking about[br]the

0:12:35.700,0:12:40.670
archetypes? Anyone paying notice? Oh, one[br]person. What, what,

0:12:40.670,0:12:41.520
what color was event?

0:12:41.520,0:12:41.990
Sorry?

0:12:41.990,0:12:42.930
AUDIENCE: Yellow.

0:12:42.930,0:12:46.710
N.H.: Yellow? Almost. It was the role. But,[br]the

0:12:46.710,0:12:49.630
event was the pink or the red. And pink's

0:12:49.630,0:12:52.520
a great color for an event, cause it highlights

0:12:52.520,0:12:56.850
sensitivity in the domain model. It's this[br]hot spot.

0:12:56.850,0:13:00.250
We'll use yellow for roles. The green for[br]the

0:13:00.250,0:13:04.520
PPTs. And the blue for the description.

0:13:04.520,0:13:06.610
So we can take a visualization of this in

0:13:06.610,0:13:09.810
terms of our domain model and add color to

0:13:09.810,0:13:13.140
that, and you can immediately see this hotspot[br]within

0:13:13.140,0:13:15.020
your domain model.

0:13:15.020,0:13:17.180
You can see the events and you can see

0:13:17.180,0:13:20.100
the other objects interacting with those events[br]through the

0:13:20.100,0:13:21.330
yellow roles.

0:13:21.330,0:13:26.220
Now, more importantly, we have this awesome[br]collaboration tool

0:13:26.220,0:13:29.520
where we can use post-it notes that correspond[br]to

0:13:29.520,0:13:32.750
these colored archetypes, and a white board,[br]and with

0:13:32.750,0:13:36.120
our team members we can collaborate in an[br]agile

0:13:36.120,0:13:42.220
manner into, on our business domain.

0:13:42.220,0:13:44.700
So now we have these four archetypes that[br]helps

0:13:44.700,0:13:48.540
us guide finding business objects in our domain.[br]But

0:13:48.540,0:13:50.910
you might have found, might have noticed that[br]it

0:13:50.910,0:13:52.529
was a little difficult for me to talk about

0:13:52.529,0:13:56.350
one object in isolation. And this leads us[br]to

0:13:56.350,0:14:02.430
our next skill, identifying collaborations.

0:14:02.430,0:14:04.620
Before moving onto collaborations, I just[br]wanted to discuss

0:14:04.620,0:14:10.000
this idea of associations versus collaborations.[br]As Rails developers,

0:14:10.000,0:14:13.100
we're very familiar with the idea of associations,[br]from,

0:14:13.100,0:14:16.970
from ActiveRecord. But associations kind of[br]have this idea

0:14:16.970,0:14:20.970
of a passive relationship, where collaborations[br]kind of communicates

0:14:20.970,0:14:24.620
this idea of an active relationship with dialogue.

0:14:24.620,0:14:27.839
And dialogue becomes very important when we[br]talk about

0:14:27.839,0:14:30.440
business rules. So I'm gonna use the idea[br]of

0:14:30.440,0:14:33.440
collaborations for the rest of this talk.

0:14:33.440,0:14:39.190
Now, identifying collaborations addresses[br]this object's responsibility of who

0:14:39.190,0:14:44.089
I know. Now, often we think about objects[br]in

0:14:44.089,0:14:48.470
isolation. We think about a customer. We think[br]about

0:14:48.470,0:14:52.029
an order. But the presence of one business[br]object

0:14:52.029,0:14:55.950
suggests the presence of another.

0:14:55.950,0:14:58.620
And this is really highlighted by this, what[br]I've

0:14:58.620,0:15:02.560
dubbed the elementary collaboration pattern.[br]So let's walk through

0:15:02.560,0:15:05.270
this. So when we have the presence of an

0:15:05.270,0:15:08.279
event, we know that that, there's a role required

0:15:08.279,0:15:10.980
to interact with that event. And if we have

0:15:10.980,0:15:14.170
roles, we need an actor. And this is our

0:15:14.170,0:15:16.450
PPTs. And, of course, if we have a collection

0:15:16.450,0:15:20.020
of PPTs, perhaps we need a description to[br]describe

0:15:20.020,0:15:21.529
that collection.

0:15:21.529,0:15:25.770
Now, this is essentially a template. And templates[br]are

0:15:25.770,0:15:30.250
meant to be modified based on need. An example

0:15:30.250,0:15:32.750
of this, if you have a PPT that only

0:15:32.750,0:15:37.000
participates in one event, do not create a[br]dedicated

0:15:37.000,0:15:39.740
role for that. That's just going to complicate[br]your

0:15:39.740,0:15:43.029
object model.

0:15:43.029,0:15:45.580
Here we have an example of a person interacting

0:15:45.580,0:15:50.029
with order. So a person can either interact[br]with

0:15:50.029,0:15:53.170
that as a customer or as a sales agent.

0:15:53.170,0:15:55.730
So, of course, the customer is the one who

0:15:55.730,0:15:57.970
is purchasing that order, and the other is[br]the,

0:15:57.970,0:16:00.070
perhaps, approving that order.

0:16:00.070,0:16:03.080
Now, we might have a business role that suggests

0:16:03.080,0:16:06.160
that we, the same person cannot be the same,

0:16:06.160,0:16:08.730
sorry, the same person cannot play the roles[br]at

0:16:08.730,0:16:11.560
the same time. Meaning they can't be the customer

0:16:11.560,0:16:13.990
and the sales agent.

0:16:13.990,0:16:18.450
There's another notation that I've introduced[br]here, in terms

0:16:18.450,0:16:20.890
of the UML, is that we have multiplicity rules

0:16:20.890,0:16:23.870
identified. So the one next to the customer[br]on

0:16:23.870,0:16:28.360
the right-hand side suggests that there's[br]a, an order

0:16:28.360,0:16:31.170
only belongs to one customer. And a customer[br]can

0:16:31.170,0:16:33.360
actually belong to many orders, and that's[br]denoted by

0:16:33.360,0:16:37.490
the zero and the asterisks next to the order.

0:16:37.490,0:16:43.060
Now, here's a description of the PPTs, sorry,[br]a

0:16:43.060,0:16:46.089
PPT versus a description. I was talking about[br]how

0:16:46.089,0:16:48.250
descriptions might be a little bit tough to[br]grasp.

0:16:48.250,0:16:50.430
We're just gonna go through an example here.

0:16:50.430,0:16:54.529
Here, we have a vehicle that's uniquely identified[br]by

0:16:54.529,0:16:57.620
a registration number. And we have a vehicle[br]make

0:16:57.620,0:17:01.620
that describes that vehicle. It describes[br]the model and

0:17:01.620,0:17:04.679
it describes the year that model was released.

0:17:04.679,0:17:07.398
Let's take a little concrete example and we'll[br]make

0:17:07.398,0:17:10.459
this a little clearer. So here we have four

0:17:10.459,0:17:15.398
instances of, of a vehicle. We have one and

0:17:15.398,0:17:18.079
two, and you'll see that there's a uniquely[br]identified

0:17:18.079,0:17:21.929
registration number. But we have duplicated[br]data here, sorry,

0:17:21.929,0:17:25.179
duplicated attributes here, with the model[br]and year.

0:17:25.179,0:17:27.730
And this is repeated again in the instances[br]three

0:17:27.730,0:17:30.720
and four. I've highlighted it here so you[br]can

0:17:30.720,0:17:34.760
see the, the repeating data.

0:17:34.760,0:17:36.760
And we can, of course, extract them. We'll[br]use

0:17:36.760,0:17:40.000
a business, business, request kind of term[br]business service

0:17:40.000,0:17:42.510
when we can extract those repeating attributes.

0:17:42.510,0:17:44.250
(weird audio - (00:17:45)

0:17:44.250,0:17:47.990
And here business object in the, with the[br]registration

0:17:47.990,0:17:50.510
number is our vehicle, and with the model[br]and

0:17:50.510,0:17:53.790
year we have the vehicle make. So the instances

0:17:53.790,0:17:56.059
of one and two of the vehicle are described

0:17:56.059,0:17:58.460
by the first instance of the description,[br]which is

0:17:58.460,0:18:02.650
the Corolla 2010. And the rows three, sorry,[br]the

0:18:02.650,0:18:05.290
instances three and four are described by[br]the second

0:18:05.290,0:18:10.230
instance of that description, the Focus 2014.

0:18:10.230,0:18:11.660
So you can sort of think about this in

0:18:11.660,0:18:17.280
the terms of data normalization.

0:18:17.280,0:18:22.090
Now, archetypes can collaborate with the same[br]archetype. So

0:18:22.090,0:18:26.059
a PPT can collaborate with another PPT. In[br]this

0:18:26.059,0:18:28.760
instance we're gonna look at event collaborations.[br]And there's

0:18:28.760,0:18:31.030
two event collaborations that we'll have a[br]look at.

0:18:31.030,0:18:34.380
The first one is the composite. The composite[br]is

0:18:34.380,0:18:37.559
actually made up of other events.

0:18:37.559,0:18:39.610
So here we have the, the composite transaction[br]and

0:18:39.610,0:18:43.520
the line item. The example is the order and

0:18:43.520,0:18:46.330
the order line item. I've introduced another[br]little bit

0:18:46.330,0:18:50.100
of UML notation with that solid, the solid[br]diamond,

0:18:50.100,0:18:55.000
and that denotes the composite within this[br]pattern.

0:18:55.000,0:18:58.650
Another event collaboration pattern is the[br]follow-up pattern, where

0:18:58.650,0:19:00.410
we have a transaction and then we have a

0:19:00.410,0:19:03.320
follow-up transaction. And in this case we[br]have an

0:19:03.320,0:19:06.670
order that is followed up by a shipment. Another

0:19:06.670,0:19:08.679
example of this would be an order followed[br]up

0:19:08.679,0:19:12.250
by a payment.

0:19:12.250,0:19:13.620
So let's sort of take a look at this

0:19:13.620,0:19:17.070
in a, in an example, a larger example. Here

0:19:17.070,0:19:20.150
we have a, a product description describing[br]a collection

0:19:20.150,0:19:23.970
of products. This product is interacting with[br]this order

0:19:23.970,0:19:26.610
line item. And this is kind of a, this,

0:19:26.610,0:19:29.110
this product interacting with a, a order line[br]item,

0:19:29.110,0:19:32.010
the idea of the thing interacting with a,[br]with

0:19:32.010,0:19:33.870
a line item. That's a common pattern that[br]you'll

0:19:33.870,0:19:37.929
see in, in domains.

0:19:37.929,0:19:39.490
But the interesting thing here is the, is[br]the

0:19:39.490,0:19:43.460
composite. And that, the highlighting's not[br]showing up very

0:19:43.460,0:19:45.290
well. I apologize for that.

0:19:45.290,0:19:47.470
But the order and the order line item is

0:19:47.470,0:19:51.260
our composite pattern that we've seen before.[br]The interesting

0:19:51.260,0:19:54.170
thing is, we repeat this pattern as well.[br]So

0:19:54.170,0:19:56.740
with a shipment and a shipment line item,[br]there

0:19:56.740,0:19:59.950
is a comp, a composite.

0:19:59.950,0:20:01.740
And we can repeat this again in terms of

0:20:01.740,0:20:04.429
the order line, sorry, the shipment line item[br]is

0:20:04.429,0:20:08.600
a follow-up for the order-line item. But this[br]is

0:20:08.600,0:20:10.770
when the magic starts to happen, is when we

0:20:10.770,0:20:14.360
had another composite with a return and return[br]line-item.

0:20:14.360,0:20:19.020
And again, and this is a collaboration, a[br]composite

0:20:19.020,0:20:19.700
collaboration.

0:20:19.700,0:20:22.840
And we can use these, these collaboration[br]patterns as

0:20:22.840,0:20:28.490
a building block in our domains as well.

0:20:28.490,0:20:31.640
And this moves us on to business rules. So,

0:20:31.640,0:20:34.340
you know, so we're talking about these collaborations,[br]but

0:20:34.340,0:20:40.380
what governs these collaborations. So business[br]rules are either

0:20:40.380,0:20:44.780
policies that specify how a business should[br]operate, or

0:20:44.780,0:20:48.620
these are constraints that are forced upon[br]a business,

0:20:48.620,0:20:52.320
such as laws determined by a government.

0:20:52.320,0:20:54.500
Now often when we think about business rules,[br]we

0:20:54.500,0:20:57.669
kind of think about validation roles, where[br]we're just

0:20:57.669,0:21:00.520
validation that an email is present, or if[br]it's

0:21:00.520,0:21:03.630
in the correct format such as using a regular

0:21:03.630,0:21:08.540
expression for that email address. But business[br]rules extend

0:21:08.540,0:21:10.400
beyond this.

0:21:10.400,0:21:13.360
They govern, or validate, collaborations.

0:21:13.360,0:21:19.660
Now, if business rules govern collaborations,[br]then each partner,

0:21:19.660,0:21:23.299
that business object, must determine if that[br]collaboration is

0:21:23.299,0:21:27.169
valid. Because each partner may have a different[br]condition

0:21:27.169,0:21:31.330
to determine if that is a valid collaboration.

0:21:31.330,0:21:34.850
Here we have an example of a shipment and

0:21:34.850,0:21:37.890
a shipping method that are looking to collaborate.[br]The

0:21:37.890,0:21:40.210
shipment has a total weight, and it might[br]be

0:21:40.210,0:21:42.740
expedited. So we want to get that shipment[br]out

0:21:42.740,0:21:43.450
quickly.

0:21:43.450,0:21:46.230
A shipping method has a, has a maximum weight

0:21:46.230,0:21:48.530
and a duration. So let's look at these two

0:21:48.530,0:21:51.820
ob, business objects collaborating.

0:21:51.820,0:21:56.350
Now, a shipping method adds a constraint on[br]its

0:21:56.350,0:22:00.200
collaboration with a shipment. It will not[br]collaborate with

0:22:00.200,0:22:05.370
a shipment whose total weight exceeds the[br]maximum weight.

0:22:05.370,0:22:10.130
Likewise, a shipment has a constraint on its[br]collaboration

0:22:10.130,0:22:14.230
with the shipping method. It will not collaborate,[br]sorry,

0:22:14.230,0:22:17.679
if that shipment is expedited, it will not[br]collaborate

0:22:17.679,0:22:21.380
with a shipment, sorry, with a shipping method[br]whose

0:22:21.380,0:22:24.360
duration exceeds two days.

0:22:24.360,0:22:29.179
So from this example, we've illustrated that[br]each partner

0:22:29.179,0:22:32.960
must validate the collaboration. And each[br]partner adds a

0:22:32.960,0:22:37.660
constraint, sorry, each partner adds a constraint[br]to that

0:22:37.660,0:22:41.169
collaboration, owns that business rule. And[br]that business rule's

0:22:41.169,0:22:45.549
encapsulated in that business object. And[br]it shields that

0:22:45.549,0:22:49.580
condition from its collaborator.

0:22:49.580,0:22:52.640
So now that we understand that business rules[br]are

0:22:52.640,0:22:57.000
simply not validation rules, that they govern[br]these collaborations,

0:22:57.000,0:23:00.400
when do these collaborations form?

0:23:00.400,0:23:02.919
And this takes us to our fourth skill or

0:23:02.919,0:23:06.260
assigning services.

0:23:06.260,0:23:09.990
And services, it's, are related to the responsibility[br]of

0:23:09.990,0:23:15.860
what I do. Now, business services respond[br]to business

0:23:15.860,0:23:21.020
requests. They form new collaborations. They[br]dissolve collaborations. And

0:23:21.020,0:23:24.890
they may even create new event objects. Of[br]course,

0:23:24.890,0:23:26.660
services can update attributes.

0:23:26.660,0:23:30.919
However, for this talk, I'm gonna focus on[br]collaboration.

0:23:30.919,0:23:34.130
Now, as a reminder, we'll just revisit this[br]scenario

0:23:34.130,0:23:36.660
from the beginning of my talk. Here, we have

0:23:36.660,0:23:40.179
a business request coming into our domain,[br]and that's

0:23:40.179,0:23:42.510
gonna be to ship an order. The order's going

0:23:42.510,0:23:44.720
to respond to that. But it's gonna check that

0:23:44.720,0:23:47.120
business rule to make sure it's being paid.[br]And

0:23:47.120,0:23:49.559
then it'll go ahead and it will create a

0:23:49.559,0:23:54.660
new shipment and collaborate with that.

0:23:54.660,0:23:56.880
So a challenge when we're object modeling[br]is that

0:23:56.880,0:24:01.600
in the real world, entities are acted upon.[br]Someone

0:24:01.600,0:24:06.120
ships an order. But when we're object modeling,[br]objects

0:24:06.120,0:24:10.419
that represent those real world entities perform[br]the actions

0:24:10.419,0:24:11.900
themselves.

0:24:11.900,0:24:15.059
So an order will ship itself. And the reason

0:24:15.059,0:24:17.910
for that is that all the information inside[br]an

0:24:17.910,0:24:22.230
object, sorry, all the information needed[br]to act on

0:24:22.230,0:24:25.250
that object is inside of that object. So let

0:24:25.250,0:24:27.200
that object do the work.

0:24:27.200,0:24:30.100
Otherwise we end up sort of creating these[br]dedicated

0:24:30.100,0:24:34.289
coordinating objects like shipment manager.[br]And an object like

0:24:34.289,0:24:38.360
shipment manager doesn't represent a real-world[br]entity and just

0:24:38.360,0:24:43.730
adds conceptual noise to our domain model.

0:24:43.730,0:24:47.210
So with this in mind, we assign this ship

0:24:47.210,0:24:50.039
service to the order, so it can respond to

0:24:50.039,0:24:54.630
that business request. And the service becomes[br]an object

0:24:54.630,0:24:57.960
factory for the shipment. And this is a pat,

0:24:57.960,0:25:02.010
and follows the pattern of services becoming[br]object factories

0:25:02.010,0:25:06.100
for events.

0:25:06.100,0:25:07.860
And here we come to our last skill, in

0:25:07.860,0:25:11.299
terms of assigning attributes. And we've already[br]taken a

0:25:11.299,0:25:15.650
look at some attributes. These attributes[br]respond to what

0:25:15.650,0:25:17.620
I know.

0:25:17.620,0:25:19.910
So coming back to our vehicle and our vehicle

0:25:19.910,0:25:24.549
make, a vehicle with its registration number[br]is a

0:25:24.549,0:25:28.880
descriptive or tacking attribute, which is[br]typical of a

0:25:28.880,0:25:32.059
PPT. With the vehicle make we have these two

0:25:32.059,0:25:37.260
descriptive attributes of a, of the model[br]and the

0:25:37.260,0:25:38.539
year.

0:25:38.539,0:25:41.200
From our order example, again, we, for the[br]order

0:25:41.200,0:25:43.720
it has this tracking attribute of a number.[br]It

0:25:43.720,0:25:46.880
knows its state and it has this time stamp

0:25:46.880,0:25:50.669
that's, that point in time events have.

0:25:50.669,0:25:56.039
Now, Jill Nicola, in her book Streamlined[br]Object Modeling,

0:25:56.039,0:25:59.730
has identified six types of attributes. I[br]won't go

0:25:59.730,0:26:02.100
through all six, but you can see some examples

0:26:02.100,0:26:03.919
on the right hand side there.

0:26:03.919,0:26:07.380
I'll focus on two attributes. The life cycle[br]state

0:26:07.380,0:26:11.460
and the operating state. The life cycle state[br]is

0:26:11.460,0:26:15.850
a, is a one-way state transition. So an order

0:26:15.850,0:26:19.940
would transition from pending to paid to complete,[br]but

0:26:19.940,0:26:22.530
it won't revert back to that stage.

0:26:22.530,0:26:26.539
An operating stage is a state that switches[br]back

0:26:26.539,0:26:30.000
and forth between two states. So an example[br]here

0:26:30.000,0:26:32.110
is a product could be active, so active in

0:26:32.110,0:26:34.830
a, in a catalog. We could switch that off

0:26:34.830,0:26:38.610
and it wouldn't appear, appear in the catalog[br]anymore.

0:26:38.610,0:26:40.090
And then we could switch it on. So it

0:26:40.090,0:26:45.250
switches back and forth.

0:26:45.250,0:26:47.580
So now that you've been introduced to the[br]five

0:26:47.580,0:26:51.520
basic skills of object modeling, we have a[br]set

0:26:51.520,0:26:54.789
of skills to bridge this gap between your[br]user

0:26:54.789,0:26:59.910
stories and your Rails application. You have[br]a framework

0:26:59.910,0:27:02.789
to explore business domains.

0:27:02.789,0:27:07.270
So, I've simply given you an introduction[br]here. And

0:27:07.270,0:27:10.179
if this talk has resonated with you, you're[br]probably

0:27:10.179,0:27:13.549
hungry for more. So I've outlined these three[br]steps

0:27:13.549,0:27:15.860
to help get you started.

0:27:15.860,0:27:19.700
First, I've created a dedicated blog post[br]providing some

0:27:19.700,0:27:24.130
online resources that, resources that you[br]can read today.

0:27:24.130,0:27:26.480
Plus links to the books that I talked about

0:27:26.480,0:27:27.799
in this talk.

0:27:27.799,0:27:32.900
Secondly, talk, share this with you team members.[br]This

0:27:32.900,0:27:35.600
idea of object modeling is awesome to use[br]as

0:27:35.600,0:27:38.130
an individual, but the real power is when[br]you

0:27:38.130,0:27:40.780
have this common language with your team mates,[br]and

0:27:40.780,0:27:43.590
collaborate with each other.

0:27:43.590,0:27:45.600
And then the third step is buy some post-it

0:27:45.600,0:27:50.330
notes. Post-it notes are an awesome collaboration[br]tool and

0:27:50.330,0:27:52.600
some, and a simple collaboration tool, and[br]it makes

0:27:52.600,0:27:57.120
this whole modeling fun.

0:27:57.120,0:28:00.159
So the next time, when a team member asks

0:28:00.159,0:28:04.320
you, how do I model this? Use archetypes to

0:28:04.320,0:28:09.830
guide you in finding objects. Use color to[br]visualize

0:28:09.830,0:28:13.340
and collaborate with your team members. Use[br]the presence

0:28:13.340,0:28:16.780
of one object to suggest the presence of another

0:28:16.780,0:28:21.780
and form collaborations. Use business rules[br]to validate or

0:28:21.780,0:28:27.400
govern these collaborations. Assign services[br]to business objects to

0:28:27.400,0:28:31.730
fulfill business requests. And use these skills[br]to build

0:28:31.730,0:28:35.840
a model that mirrors the business, enabling[br]you to

0:28:35.840,0:28:39.929
correctly and efficiently understand the domain.

0:28:39.929,0:28:41.889
Thank you.