WEBVTT 00:00:16.760 --> 00:00:20.810 NICHOLAS HENRY: Good morning. 00:00:20.810 --> 00:00:24.119 How many of you have read or heard of the book, 00:00:24.119 --> 00:00:25.619 Drawing on the Right Side of the Brain? 00:00:25.619 --> 00:00:28.750 OK. We've got a, we've got a few people. 00:00:28.750 --> 00:00:30.310 All right. Excellent. 00:00:30.310 --> 00:00:32.070 For those who don't know, this book was authored 00:00:32.070 --> 00:00:36.730 by Betty Edwards. It was originally published in 1979, 00:00:36.730 --> 00:00:40.540 and this latest edition was published in 1999. And 00:00:40.540 --> 00:00:43.390 it dispelled this myth that drawing was a talent 00:00:43.390 --> 00:00:45.710 that you were born with. And it's actually a 00:00:45.710 --> 00:00:47.980 skill that can be learned. 00:00:47.980 --> 00:00:52.830 Now, one of these skills is viewing negative space. 00:00:52.830 --> 00:00:55.129 The idea that you draw the ob- you don't 00:00:55.129 --> 00:00:57.659 draw the object, but you draw the spaces in 00:00:57.659 --> 00:01:01.210 between the object. And this tricks the brain. It 00:01:01.210 --> 00:01:03.290 switches the brain from a left mode to a 00:01:03.290 --> 00:01:06.440 logical think- from a logical thinking mode to a 00:01:06.440 --> 00:01:09.460 right-brain or a perceptual mode. 00:01:09.460 --> 00:01:11.750 And the benefit of this is when we're making 00:01:11.750 --> 00:01:16.369 logical decisions, but we make bad perceptual decisions. Great 00:01:16.369 --> 00:01:18.860 example is this chair. If you look at the 00:01:18.860 --> 00:01:21.720 chair, you'll see the legs are quite thin. And 00:01:21.720 --> 00:01:23.830 logically you think, man, if I sit on that 00:01:23.830 --> 00:01:25.670 chair, that's not gonna hold. That's not gonna support 00:01:25.670 --> 00:01:28.940 a person. And so logically would go, would increase 00:01:28.940 --> 00:01:31.190 the size of those legs, and we end up 00:01:31.190 --> 00:01:33.170 distorting the, the picture. 00:01:33.170 --> 00:01:39.810 Betty Edwards describes drawing as five, sorry, she describes 00:01:39.810 --> 00:01:43.700 drawing as a global skill, consisting of five basic 00:01:43.700 --> 00:01:48.840 skills. And she describes these skills as perceptual skills. 00:01:48.840 --> 00:01:52.920 The ability to correctly and efficiently understand what is 00:01:52.920 --> 00:01:54.920 being seen. 00:01:54.920 --> 00:01:57.140 I'm Nicholas Henry, and I'd like to welcome you 00:01:57.140 --> 00:01:59.700 to my talk, Modeling on the Right Side of 00:01:59.700 --> 00:02:02.090 the Brain, where I'll introduce you to the five 00:02:02.090 --> 00:02:06.280 basic skills of object-modeling. We will explore using color 00:02:06.280 --> 00:02:09.619 and patterns to help you visualize and communicate and 00:02:09.619 --> 00:02:13.340 understand the main models. 00:02:13.340 --> 00:02:16.390 And the five basic skills for object-modeling are finding 00:02:16.390 --> 00:02:23.370 objects, identifying collaborations, defining business rules, and assigning services 00:02:23.370 --> 00:02:26.030 and attributes. 00:02:26.030 --> 00:02:27.359 So I just want to make sure we're all 00:02:27.359 --> 00:02:29.950 on the same page, in, in terms of what 00:02:29.950 --> 00:02:32.260 a domain model is. So we're just gonna review 00:02:32.260 --> 00:02:35.469 the scenario of shipping an order, which would behest 00:02:35.469 --> 00:02:37.519 be an economist domain. 00:02:37.519 --> 00:02:41.739 Now, a domain really represents a business process. So 00:02:41.739 --> 00:02:44.150 let's go through, through this example. So we have 00:02:44.150 --> 00:02:47.279 a business request that comes into our domain. In 00:02:47.279 --> 00:02:50.709 this case it's to ship an order. An order 00:02:50.709 --> 00:02:54.739 which represents a business object will receive this, and 00:02:54.739 --> 00:02:57.639 it will go ahead and create a shipment. Another 00:02:57.639 --> 00:03:00.290 business object that it'll collaborate with. 00:03:00.290 --> 00:03:02.579 But we probably want to make sure that order's 00:03:02.579 --> 00:03:04.879 been paid for before we ship that order. It 00:03:04.879 --> 00:03:07.659 probably wouldn't make much sense, business sense, right. So 00:03:07.659 --> 00:03:10.420 we have a business role that will check that 00:03:10.420 --> 00:03:12.719 that order's actually been paid for. 00:03:12.719 --> 00:03:17.379 So, essentially, a business domain, or a domain model, 00:03:17.379 --> 00:03:20.900 is a set of business objects that represent these 00:03:20.900 --> 00:03:25.639 real-world entities. There are collaborations, there are business rules, 00:03:25.639 --> 00:03:29.909 and there are services that respond to business requests. 00:03:29.909 --> 00:03:33.400 Now, a model is simply a representation of something. 00:03:33.400 --> 00:03:36.359 It could be a mental model, our mental understanding 00:03:36.359 --> 00:03:39.230 of how a business process works. It might be 00:03:39.230 --> 00:03:42.230 a graphical notation or, sorry, a graphical model such 00:03:42.230 --> 00:03:44.959 as a notation that I'm using up here. Or 00:03:44.959 --> 00:03:47.889 it might even be codified in your models directory 00:03:47.889 --> 00:03:49.689 in your Rails application. 00:03:49.689 --> 00:03:53.239 Of course, there are other concerns when you're building 00:03:53.239 --> 00:03:56.389 an application. These things like persisting those business objects 00:03:56.389 --> 00:04:01.809 to a database, generating HTML or JSON, or even 00:04:01.809 --> 00:04:05.439 handling that HTTP request that comes into your controller. 00:04:05.439 --> 00:04:07.650 But these are things that are outside of your 00:04:07.650 --> 00:04:09.859 domain model. And you can, can think of the 00:04:09.859 --> 00:04:15.779 domain model as the heart of your application. 00:04:15.779 --> 00:04:17.880 So I use this term business services when a 00:04:17.880 --> 00:04:21.060 business request comes in, we'll use a business service 00:04:21.060 --> 00:04:24.449 to respond to that request. Now, this is where 00:04:24.449 --> 00:04:26.800 the services that you might have heard in the 00:04:26.800 --> 00:04:30.410 previous talk on domain-driven design, and it's a pattern 00:04:30.410 --> 00:04:33.350 that Rails developers have developed over the last couple 00:04:33.350 --> 00:04:35.670 of years, where we create a service class to 00:04:35.670 --> 00:04:38.850 encapsulate logic such as, sort of, sending out an 00:04:38.850 --> 00:04:44.070 email or finding, finding a user record. 00:04:44.070 --> 00:04:45.500 And the idea is to kind of thin down 00:04:45.500 --> 00:04:48.280 the responsibilities of the controller. When I use the 00:04:48.280 --> 00:04:50.760 term service, I'm not referring to that. I'm referring 00:04:50.760 --> 00:04:53.910 to this idea of responding to a business request. 00:04:53.910 --> 00:04:56.160 I'll try to use the, the term business service 00:04:56.160 --> 00:05:02.120 to differentiate from this idea of a service class. 00:05:02.120 --> 00:05:05.950 So why, why object modeling? Well, it feels like 00:05:05.950 --> 00:05:08.900 there's a gap between user stories. You know, user 00:05:08.900 --> 00:05:12.100 stories are great at requirements gathering. They're great for 00:05:12.100 --> 00:05:17.980 describing business requests at, from the end user's perspective. 00:05:17.980 --> 00:05:19.850 But how do we take those requirements and then 00:05:19.850 --> 00:05:22.510 go ahead and implement that model in our Rails 00:05:22.510 --> 00:05:23.170 application? 00:05:23.170 --> 00:05:26.940 It's almost like we're missing a tool. We're missing 00:05:26.940 --> 00:05:30.780 a tool to represent this underlying business model. A 00:05:30.780 --> 00:05:33.880 tool to identify the business objects that represent these 00:05:33.880 --> 00:05:38.380 real-world entities. A tool to define the define rules 00:05:38.380 --> 00:05:40.590 that govern these collaborations. 00:05:40.590 --> 00:05:43.720 I think as Rails developers, we kind of lack 00:05:43.720 --> 00:05:47.020 a language, in terms of talking about domains. Normally, 00:05:47.020 --> 00:05:49.440 we talk about domains in the form of associations 00:05:49.440 --> 00:05:53.500 and has_many and belongs_to. 00:05:53.500 --> 00:05:55.900 Object modeling is a practice, and these five basic 00:05:55.900 --> 00:05:58.640 skills will help us bridge this gap between user 00:05:58.640 --> 00:06:02.190 stories and implementation. Now, I just want to be 00:06:02.190 --> 00:06:05.050 clear in terms of setting expectations for this talk. 00:06:05.050 --> 00:06:08.160 I'm not gonna be showing any code. OK. Great. 00:06:08.160 --> 00:06:10.790 No one got up and left. That's a good 00:06:10.790 --> 00:06:11.250 sign. 00:06:11.250 --> 00:06:13.890 And, so there's gonna be no code examples. And 00:06:13.890 --> 00:06:15.580 there'll be lots of talks that are, over the 00:06:15.580 --> 00:06:18.610 next couple of days, you know, showing different implementations. 00:06:18.610 --> 00:06:21.230 And the thing is with this, with this practice 00:06:21.230 --> 00:06:24.780 of object modeling, I believe it's independent of implementation. 00:06:24.780 --> 00:06:28.330 It just helps you understand the business model itself. 00:06:28.330 --> 00:06:32.380 Now, this idea of, this practice of object modeling, 00:06:32.380 --> 00:06:35.580 it's not new. And Peter Coad first discussed this 00:06:35.580 --> 00:06:39.970 in his book, Java Modeling in Color with UML. 00:06:39.970 --> 00:06:43.010 This was first published in 1999. And, this is 00:06:43.010 --> 00:06:45.670 not gonna be a popular book for Rubyists, right. 00:06:45.670 --> 00:06:47.410 It has two things going wrong with it. It 00:06:47.410 --> 00:06:51.340 has Java and UML in the title. 00:06:51.340 --> 00:06:52.740 But there were some other books that were published 00:06:52.740 --> 00:06:55.020 around the time, and other ones such as Streamlined 00:06:55.020 --> 00:06:58.430 Object Modeling by Jill Nicola. And this really influenced 00:06:58.430 --> 00:07:01.990 my thinking in terms of how to understand a 00:07:01.990 --> 00:07:04.360 business domain. 00:07:04.360 --> 00:07:07.110 And what I like about object modeling is that 00:07:07.110 --> 00:07:10.100 it provides us a framework. Very much like Rails 00:07:10.100 --> 00:07:13.500 provides us a framework in terms of providing us 00:07:13.500 --> 00:07:17.420 guidance in terms of structuring our application. It provides 00:07:17.420 --> 00:07:21.770 us conventions. And it helps us accelerate our web 00:07:21.770 --> 00:07:22.540 development. 00:07:22.540 --> 00:07:24.550 And object modeling's a little like that. It allows 00:07:24.550 --> 00:07:27.930 us to discuss, visualize, and help us, guide us 00:07:27.930 --> 00:07:30.820 in terms of implementing those domains. But it also, 00:07:30.820 --> 00:07:34.580 it helps us to accelerate our understanding of those 00:07:34.580 --> 00:07:35.980 business domains. 00:07:35.980 --> 00:07:40.370 Now, I'm not advocating any big upfront design. This 00:07:40.370 --> 00:07:44.360 is simply a tool to sketch out those ideas, 00:07:44.360 --> 00:07:47.240 to collaborate with your team members and help guide 00:07:47.240 --> 00:07:50.730 your implementation. Sure, the diagrams that I'm going to 00:07:50.730 --> 00:07:54.480 be using today are URML, UML, the unified modeling 00:07:54.480 --> 00:07:59.330 language. But these are simply communication tools. The goal 00:07:59.330 --> 00:08:02.380 is not the diagrams themselves. 00:08:02.380 --> 00:08:07.290 Now as object modelers, our basic building blocks are 00:08:07.290 --> 00:08:10.020 objects. Which is fantastic, cause as Rubyists, we work 00:08:10.020 --> 00:08:13.020 in a object-oriented language. Now, when I speak about 00:08:13.020 --> 00:08:16.340 objects, I'm going to speak in the first person. 00:08:16.340 --> 00:08:20.030 And this helps us personify these objects. 00:08:20.030 --> 00:08:26.870 So objects have three responsibilities. Who I know, what 00:08:26.870 --> 00:08:31.930 I do, and what I know. 00:08:31.930 --> 00:08:34.019 An example of that, coming back to an order, 00:08:34.019 --> 00:08:36.089 an order would know a number, it would know 00:08:36.089 --> 00:08:38.360 its state - if it's paid. It would know 00:08:38.360 --> 00:08:40.950 a timestamp for when it was purchased at. Of 00:08:40.950 --> 00:08:43.269 course, it knows other collaborators. So it knows a 00:08:43.269 --> 00:08:46.019 shipment and it knows how to ship itself: its 00:08:46.019 --> 00:08:49.060 business service. 00:08:49.060 --> 00:08:51.110 So now that we have this building block, let's 00:08:51.110 --> 00:08:56.050 look at finding objects, our first skill. 00:08:56.050 --> 00:08:58.610 The problem with finding objects is that often we 00:08:58.610 --> 00:09:01.779 look at business objects as unique. They're these pretty 00:09:01.779 --> 00:09:05.020 little snow flakes. But in effect, we can group 00:09:05.020 --> 00:09:09.330 objects with more or less the same responsibilities of 00:09:09.330 --> 00:09:12.140 what, who I know, what I do, and what 00:09:12.140 --> 00:09:13.800 I know. 00:09:13.800 --> 00:09:16.460 And these groups are known as archetypes, the term 00:09:16.460 --> 00:09:18.550 that Peter Coad assigned to this. And we have 00:09:18.550 --> 00:09:22.810 four archetypes. We have an event, a role, a 00:09:22.810 --> 00:09:27.160 party, place, or thing, or a description. Party, place, 00:09:27.160 --> 00:09:29.330 or thing's a little bit of a mouthful to 00:09:29.330 --> 00:09:31.290 say every time, so we'll refer to these as 00:09:31.290 --> 00:09:34.340 the PPTs. 00:09:34.340 --> 00:09:37.540 So let's look at our first archetype. Our first 00:09:37.540 --> 00:09:40.540 archetype are events. And these are modeled as transactions 00:09:40.540 --> 00:09:44.710 within our domain. They're the most important business objects. 00:09:44.710 --> 00:09:47.270 They're the glue for all the other objects in 00:09:47.270 --> 00:09:51.090 our business domain. And without an event, I would 00:09:51.090 --> 00:09:55.950 assert the application is simply a catalog application. 00:09:55.950 --> 00:09:57.920 So we've got some examples up here. So in 00:09:57.920 --> 00:09:59.620 the, in the domain of the ecommerce we would 00:09:59.620 --> 00:10:02.440 have an order and a shipment. These are transactions 00:10:02.440 --> 00:10:05.670 within that domain. If we're modeling a hotel reservation 00:10:05.670 --> 00:10:08.870 system or a car reservation, we'd have a reservation 00:10:08.870 --> 00:10:11.800 event. 00:10:11.800 --> 00:10:14.190 And we have two types of events. We have 00:10:14.190 --> 00:10:16.870 a point in time and an interval. So a 00:10:16.870 --> 00:10:19.420 point in time has a single timestamp, such as 00:10:19.420 --> 00:10:23.080 order, with the purchased_at date. And then we have 00:10:23.080 --> 00:10:28.870 reservation. A reserv- sorry. We have an internal archetype, 00:10:28.870 --> 00:10:31.360 illustrated by the reservation here. 00:10:31.360 --> 00:10:34.550 And this is timestamped, or bookend by two timestamps. 00:10:34.550 --> 00:10:38.510 So the checkin_at date and the checkout. 00:10:38.510 --> 00:10:42.450 Now, roles don't live in isolation. They, they're the 00:10:42.450 --> 00:10:45.740 glue in the domain. And other objects interact in 00:10:45.740 --> 00:10:49.610 this event. And we use roles to represent the 00:10:49.610 --> 00:10:54.440 way an object participates in this event. So as 00:10:54.440 --> 00:10:56.580 an example, we have a customer and a sales 00:10:56.580 --> 00:10:59.330 agent that would interact with an order. And a 00:10:59.330 --> 00:11:03.820 fulfillment provider that would interact with the shipment. 00:11:03.820 --> 00:11:08.360 So if we have roles, then we need actors. 00:11:08.360 --> 00:11:10.920 And the actors in our domain, as, are these, 00:11:10.920 --> 00:11:15.060 is the PPTs. Now, so, a party would be 00:11:15.060 --> 00:11:19.430 a person or an organization. The place would be, 00:11:19.430 --> 00:11:21.650 such of a thing as a warehouse if we 00:11:21.650 --> 00:11:24.350 were doing shipment. And everything else is a thing. 00:11:24.350 --> 00:11:26.670 So, again, an example here is the, is the 00:11:26.670 --> 00:11:27.839 product. 00:11:27.839 --> 00:11:33.810 And our final archetype is a description. And descriptions 00:11:33.810 --> 00:11:38.600 are responsible for describing a collection of similar objects, 00:11:38.600 --> 00:11:41.380 such as our PPTs. An example of this would 00:11:41.380 --> 00:11:44.529 be a product category that would describe a, a 00:11:44.529 --> 00:11:46.830 collection of products. A collection of things such as 00:11:46.830 --> 00:11:50.130 t-shirts. Or a collection of jeans on an ecommerce 00:11:50.130 --> 00:11:50.740 site. 00:11:50.740 --> 00:11:54.180 Now, the concept of a description object can be 00:11:54.180 --> 00:11:56.980 a little tough to kind of grasp sometimes. So 00:11:56.980 --> 00:11:58.430 I'll talk about this in a little bit more 00:11:58.430 --> 00:12:02.710 detail when we talk about identifying collaborations. 00:12:02.710 --> 00:12:08.740 Now, when we're collaborating or presenting a diagram visually, 00:12:08.740 --> 00:12:10.480 as soon as we have a few business objects 00:12:10.480 --> 00:12:12.680 on a, on a diagram, it becomes a little 00:12:12.680 --> 00:12:15.680 tough to navigate. Don't worry, you're not supposed to 00:12:15.680 --> 00:12:19.089 be able to read all the details here. I'm 00:12:19.089 --> 00:12:21.350 just gonna illustrate something. 00:12:21.350 --> 00:12:23.690 But we can solve this issue in, in terms 00:12:23.690 --> 00:12:27.940 of navigating these diagrams. We can add color, to 00:12:27.940 --> 00:12:33.529 give another layer of information. Did anyone notice the 00:12:33.529 --> 00:12:35.700 slides change color when I was talking about the 00:12:35.700 --> 00:12:40.670 archetypes? Anyone paying notice? Oh, one person. What, what, 00:12:40.670 --> 00:12:41.520 what color was event? 00:12:41.520 --> 00:12:41.990 Sorry? 00:12:41.990 --> 00:12:42.930 AUDIENCE: Yellow. 00:12:42.930 --> 00:12:46.710 N.H.: Yellow? Almost. It was the role. But, the 00:12:46.710 --> 00:12:49.630 event was the pink or the red. And pink's 00:12:49.630 --> 00:12:52.520 a great color for an event, cause it highlights 00:12:52.520 --> 00:12:56.850 sensitivity in the domain model. It's this hot spot. 00:12:56.850 --> 00:13:00.250 We'll use yellow for roles. The green for the 00:13:00.250 --> 00:13:04.520 PPTs. And the blue for the description. 00:13:04.520 --> 00:13:06.610 So we can take a visualization of this in 00:13:06.610 --> 00:13:09.810 terms of our domain model and add color to 00:13:09.810 --> 00:13:13.140 that, and you can immediately see this hotspot within 00:13:13.140 --> 00:13:15.020 your domain model. 00:13:15.020 --> 00:13:17.180 You can see the events and you can see 00:13:17.180 --> 00:13:20.100 the other objects interacting with those events through the 00:13:20.100 --> 00:13:21.330 yellow roles. 00:13:21.330 --> 00:13:26.220 Now, more importantly, we have this awesome collaboration tool 00:13:26.220 --> 00:13:29.520 where we can use post-it notes that correspond to 00:13:29.520 --> 00:13:32.750 these colored archetypes, and a white board, and with 00:13:32.750 --> 00:13:36.120 our team members we can collaborate in an agile 00:13:36.120 --> 00:13:42.220 manner into, on our business domain. 00:13:42.220 --> 00:13:44.700 So now we have these four archetypes that helps 00:13:44.700 --> 00:13:48.540 us guide finding business objects in our domain. But 00:13:48.540 --> 00:13:50.910 you might have found, might have noticed that it 00:13:50.910 --> 00:13:52.529 was a little difficult for me to talk about 00:13:52.529 --> 00:13:56.350 one object in isolation. And this leads us to 00:13:56.350 --> 00:14:02.430 our next skill, identifying collaborations. 00:14:02.430 --> 00:14:04.620 Before moving onto collaborations, I just wanted to discuss 00:14:04.620 --> 00:14:10.000 this idea of associations versus collaborations. As Rails developers, 00:14:10.000 --> 00:14:13.100 we're very familiar with the idea of associations, from, 00:14:13.100 --> 00:14:16.970 from ActiveRecord. But associations kind of have this idea 00:14:16.970 --> 00:14:20.970 of a passive relationship, where collaborations kind of communicates 00:14:20.970 --> 00:14:24.620 this idea of an active relationship with dialogue. 00:14:24.620 --> 00:14:27.839 And dialogue becomes very important when we talk about 00:14:27.839 --> 00:14:30.440 business rules. So I'm gonna use the idea of 00:14:30.440 --> 00:14:33.440 collaborations for the rest of this talk. 00:14:33.440 --> 00:14:39.190 Now, identifying collaborations addresses this object's responsibility of who 00:14:39.190 --> 00:14:44.089 I know. Now, often we think about objects in 00:14:44.089 --> 00:14:48.470 isolation. We think about a customer. We think about 00:14:48.470 --> 00:14:52.029 an order. But the presence of one business object 00:14:52.029 --> 00:14:55.950 suggests the presence of another. 00:14:55.950 --> 00:14:58.620 And this is really highlighted by this, what I've 00:14:58.620 --> 00:15:02.560 dubbed the elementary collaboration pattern. So let's walk through 00:15:02.560 --> 00:15:05.270 this. So when we have the presence of an 00:15:05.270 --> 00:15:08.279 event, we know that that, there's a role required 00:15:08.279 --> 00:15:10.980 to interact with that event. And if we have 00:15:10.980 --> 00:15:14.170 roles, we need an actor. And this is our 00:15:14.170 --> 00:15:16.450 PPTs. And, of course, if we have a collection 00:15:16.450 --> 00:15:20.020 of PPTs, perhaps we need a description to describe 00:15:20.020 --> 00:15:21.529 that collection. 00:15:21.529 --> 00:15:25.770 Now, this is essentially a template. And templates are 00:15:25.770 --> 00:15:30.250 meant to be modified based on need. An example 00:15:30.250 --> 00:15:32.750 of this, if you have a PPT that only 00:15:32.750 --> 00:15:37.000 participates in one event, do not create a dedicated 00:15:37.000 --> 00:15:39.740 role for that. That's just going to complicate your 00:15:39.740 --> 00:15:43.029 object model. 00:15:43.029 --> 00:15:45.580 Here we have an example of a person interacting 00:15:45.580 --> 00:15:50.029 with order. So a person can either interact with 00:15:50.029 --> 00:15:53.170 that as a customer or as a sales agent. 00:15:53.170 --> 00:15:55.730 So, of course, the customer is the one who 00:15:55.730 --> 00:15:57.970 is purchasing that order, and the other is the, 00:15:57.970 --> 00:16:00.070 perhaps, approving that order. 00:16:00.070 --> 00:16:03.080 Now, we might have a business role that suggests 00:16:03.080 --> 00:16:06.160 that we, the same person cannot be the same, 00:16:06.160 --> 00:16:08.730 sorry, the same person cannot play the roles at 00:16:08.730 --> 00:16:11.560 the same time. Meaning they can't be the customer 00:16:11.560 --> 00:16:13.990 and the sales agent. 00:16:13.990 --> 00:16:18.450 There's another notation that I've introduced here, in terms 00:16:18.450 --> 00:16:20.890 of the UML, is that we have multiplicity rules 00:16:20.890 --> 00:16:23.870 identified. So the one next to the customer on 00:16:23.870 --> 00:16:28.360 the right-hand side suggests that there's a, an order 00:16:28.360 --> 00:16:31.170 only belongs to one customer. And a customer can 00:16:31.170 --> 00:16:33.360 actually belong to many orders, and that's denoted by 00:16:33.360 --> 00:16:37.490 the zero and the asterisks next to the order. 00:16:37.490 --> 00:16:43.060 Now, here's a description of the PPTs, sorry, a 00:16:43.060 --> 00:16:46.089 PPT versus a description. I was talking about how 00:16:46.089 --> 00:16:48.250 descriptions might be a little bit tough to grasp. 00:16:48.250 --> 00:16:50.430 We're just gonna go through an example here. 00:16:50.430 --> 00:16:54.529 Here, we have a vehicle that's uniquely identified by 00:16:54.529 --> 00:16:57.620 a registration number. And we have a vehicle make 00:16:57.620 --> 00:17:01.620 that describes that vehicle. It describes the model and 00:17:01.620 --> 00:17:04.679 it describes the year that model was released. 00:17:04.679 --> 00:17:07.398 Let's take a little concrete example and we'll make 00:17:07.398 --> 00:17:10.459 this a little clearer. So here we have four 00:17:10.459 --> 00:17:15.398 instances of, of a vehicle. We have one and 00:17:15.398 --> 00:17:18.079 two, and you'll see that there's a uniquely identified 00:17:18.079 --> 00:17:21.929 registration number. But we have duplicated data here, sorry, 00:17:21.929 --> 00:17:25.179 duplicated attributes here, with the model and year. 00:17:25.179 --> 00:17:27.730 And this is repeated again in the instances three 00:17:27.730 --> 00:17:30.720 and four. I've highlighted it here so you can 00:17:30.720 --> 00:17:34.760 see the, the repeating data. 00:17:34.760 --> 00:17:36.760 And we can, of course, extract them. We'll use 00:17:36.760 --> 00:17:40.000 a business, business, request kind of term business service 00:17:40.000 --> 00:17:42.510 when we can extract those repeating attributes. 00:17:42.510 --> 00:17:44.250 (weird audio - (00:17:45) 00:17:44.250 --> 00:17:47.990 And here business object in the, with the registration 00:17:47.990 --> 00:17:50.510 number is our vehicle, and with the model and 00:17:50.510 --> 00:17:53.790 year we have the vehicle make. So the instances 00:17:53.790 --> 00:17:56.059 of one and two of the vehicle are described 00:17:56.059 --> 00:17:58.460 by the first instance of the description, which is 00:17:58.460 --> 00:18:02.650 the Corolla 2010. And the rows three, sorry, the 00:18:02.650 --> 00:18:05.290 instances three and four are described by the second 00:18:05.290 --> 00:18:10.230 instance of that description, the Focus 2014. 00:18:10.230 --> 00:18:11.660 So you can sort of think about this in 00:18:11.660 --> 00:18:17.280 the terms of data normalization. 00:18:17.280 --> 00:18:22.090 Now, archetypes can collaborate with the same archetype. So 00:18:22.090 --> 00:18:26.059 a PPT can collaborate with another PPT. In this 00:18:26.059 --> 00:18:28.760 instance we're gonna look at event collaborations. And there's 00:18:28.760 --> 00:18:31.030 two event collaborations that we'll have a look at. 00:18:31.030 --> 00:18:34.380 The first one is the composite. The composite is 00:18:34.380 --> 00:18:37.559 actually made up of other events. 00:18:37.559 --> 00:18:39.610 So here we have the, the composite transaction and 00:18:39.610 --> 00:18:43.520 the line item. The example is the order and 00:18:43.520 --> 00:18:46.330 the order line item. I've introduced another little bit 00:18:46.330 --> 00:18:50.100 of UML notation with that solid, the solid diamond, 00:18:50.100 --> 00:18:55.000 and that denotes the composite within this pattern. 00:18:55.000 --> 00:18:58.650 Another event collaboration pattern is the follow-up pattern, where 00:18:58.650 --> 00:19:00.410 we have a transaction and then we have a 00:19:00.410 --> 00:19:03.320 follow-up transaction. And in this case we have an 00:19:03.320 --> 00:19:06.670 order that is followed up by a shipment. Another 00:19:06.670 --> 00:19:08.679 example of this would be an order followed up 00:19:08.679 --> 00:19:12.250 by a payment. 00:19:12.250 --> 00:19:13.620 So let's sort of take a look at this 00:19:13.620 --> 00:19:17.070 in a, in an example, a larger example. Here 00:19:17.070 --> 00:19:20.150 we have a, a product description describing a collection 00:19:20.150 --> 00:19:23.970 of products. This product is interacting with this order 00:19:23.970 --> 00:19:26.610 line item. And this is kind of a, this, 00:19:26.610 --> 00:19:29.110 this product interacting with a, a order line item, 00:19:29.110 --> 00:19:32.010 the idea of the thing interacting with a, with 00:19:32.010 --> 00:19:33.870 a line item. That's a common pattern that you'll 00:19:33.870 --> 00:19:37.929 see in, in domains. 00:19:37.929 --> 00:19:39.490 But the interesting thing here is the, is the 00:19:39.490 --> 00:19:43.460 composite. And that, the highlighting's not showing up very 00:19:43.460 --> 00:19:45.290 well. I apologize for that. 00:19:45.290 --> 00:19:47.470 But the order and the order line item is 00:19:47.470 --> 00:19:51.260 our composite pattern that we've seen before. The interesting 00:19:51.260 --> 00:19:54.170 thing is, we repeat this pattern as well. So 00:19:54.170 --> 00:19:56.740 with a shipment and a shipment line item, there 00:19:56.740 --> 00:19:59.950 is a comp, a composite. 00:19:59.950 --> 00:20:01.740 And we can repeat this again in terms of 00:20:01.740 --> 00:20:04.429 the order line, sorry, the shipment line item is 00:20:04.429 --> 00:20:08.600 a follow-up for the order-line item. But this is 00:20:08.600 --> 00:20:10.770 when the magic starts to happen, is when we 00:20:10.770 --> 00:20:14.360 had another composite with a return and return line-item. 00:20:14.360 --> 00:20:19.020 And again, and this is a collaboration, a composite 00:20:19.020 --> 00:20:19.700 collaboration. 00:20:19.700 --> 00:20:22.840 And we can use these, these collaboration patterns as 00:20:22.840 --> 00:20:28.490 a building block in our domains as well. 00:20:28.490 --> 00:20:31.640 And this moves us on to business rules. So, 00:20:31.640 --> 00:20:34.340 you know, so we're talking about these collaborations, but 00:20:34.340 --> 00:20:40.380 what governs these collaborations. So business rules are either 00:20:40.380 --> 00:20:44.780 policies that specify how a business should operate, or 00:20:44.780 --> 00:20:48.620 these are constraints that are forced upon a business, 00:20:48.620 --> 00:20:52.320 such as laws determined by a government. 00:20:52.320 --> 00:20:54.500 Now often when we think about business rules, we 00:20:54.500 --> 00:20:57.669 kind of think about validation roles, where we're just 00:20:57.669 --> 00:21:00.520 validation that an email is present, or if it's 00:21:00.520 --> 00:21:03.630 in the correct format such as using a regular 00:21:03.630 --> 00:21:08.540 expression for that email address. But business rules extend 00:21:08.540 --> 00:21:10.400 beyond this. 00:21:10.400 --> 00:21:13.360 They govern, or validate, collaborations. 00:21:13.360 --> 00:21:19.660 Now, if business rules govern collaborations, then each partner, 00:21:19.660 --> 00:21:23.299 that business object, must determine if that collaboration is 00:21:23.299 --> 00:21:27.169 valid. Because each partner may have a different condition 00:21:27.169 --> 00:21:31.330 to determine if that is a valid collaboration. 00:21:31.330 --> 00:21:34.850 Here we have an example of a shipment and 00:21:34.850 --> 00:21:37.890 a shipping method that are looking to collaborate. The 00:21:37.890 --> 00:21:40.210 shipment has a total weight, and it might be 00:21:40.210 --> 00:21:42.740 expedited. So we want to get that shipment out 00:21:42.740 --> 00:21:43.450 quickly. 00:21:43.450 --> 00:21:46.230 A shipping method has a, has a maximum weight 00:21:46.230 --> 00:21:48.530 and a duration. So let's look at these two 00:21:48.530 --> 00:21:51.820 ob, business objects collaborating. 00:21:51.820 --> 00:21:56.350 Now, a shipping method adds a constraint on its 00:21:56.350 --> 00:22:00.200 collaboration with a shipment. It will not collaborate with 00:22:00.200 --> 00:22:05.370 a shipment whose total weight exceeds the maximum weight. 00:22:05.370 --> 00:22:10.130 Likewise, a shipment has a constraint on its collaboration 00:22:10.130 --> 00:22:14.230 with the shipping method. It will not collaborate, sorry, 00:22:14.230 --> 00:22:17.679 if that shipment is expedited, it will not collaborate 00:22:17.679 --> 00:22:21.380 with a shipment, sorry, with a shipping method whose 00:22:21.380 --> 00:22:24.360 duration exceeds two days. 00:22:24.360 --> 00:22:29.179 So from this example, we've illustrated that each partner 00:22:29.179 --> 00:22:32.960 must validate the collaboration. And each partner adds a 00:22:32.960 --> 00:22:37.660 constraint, sorry, each partner adds a constraint to that 00:22:37.660 --> 00:22:41.169 collaboration, owns that business rule. And that business rule's 00:22:41.169 --> 00:22:45.549 encapsulated in that business object. And it shields that 00:22:45.549 --> 00:22:49.580 condition from its collaborator. 00:22:49.580 --> 00:22:52.640 So now that we understand that business rules are 00:22:52.640 --> 00:22:57.000 simply not validation rules, that they govern these collaborations, 00:22:57.000 --> 00:23:00.400 when do these collaborations form? 00:23:00.400 --> 00:23:02.919 And this takes us to our fourth skill or 00:23:02.919 --> 00:23:06.260 assigning services. 00:23:06.260 --> 00:23:09.990 And services, it's, are related to the responsibility of 00:23:09.990 --> 00:23:15.860 what I do. Now, business services respond to business 00:23:15.860 --> 00:23:21.020 requests. They form new collaborations. They dissolve collaborations. And 00:23:21.020 --> 00:23:24.890 they may even create new event objects. Of course, 00:23:24.890 --> 00:23:26.660 services can update attributes. 00:23:26.660 --> 00:23:30.919 However, for this talk, I'm gonna focus on collaboration. 00:23:30.919 --> 00:23:34.130 Now, as a reminder, we'll just revisit this scenario 00:23:34.130 --> 00:23:36.660 from the beginning of my talk. Here, we have 00:23:36.660 --> 00:23:40.179 a business request coming into our domain, and that's 00:23:40.179 --> 00:23:42.510 gonna be to ship an order. The order's going 00:23:42.510 --> 00:23:44.720 to respond to that. But it's gonna check that 00:23:44.720 --> 00:23:47.120 business rule to make sure it's being paid. And 00:23:47.120 --> 00:23:49.559 then it'll go ahead and it will create a 00:23:49.559 --> 00:23:54.660 new shipment and collaborate with that. 00:23:54.660 --> 00:23:56.880 So a challenge when we're object modeling is that 00:23:56.880 --> 00:24:01.600 in the real world, entities are acted upon. Someone 00:24:01.600 --> 00:24:06.120 ships an order. But when we're object modeling, objects 00:24:06.120 --> 00:24:10.419 that represent those real world entities perform the actions 00:24:10.419 --> 00:24:11.900 themselves. 00:24:11.900 --> 00:24:15.059 So an order will ship itself. And the reason 00:24:15.059 --> 00:24:17.910 for that is that all the information inside an 00:24:17.910 --> 00:24:22.230 object, sorry, all the information needed to act on 00:24:22.230 --> 00:24:25.250 that object is inside of that object. So let 00:24:25.250 --> 00:24:27.200 that object do the work. 00:24:27.200 --> 00:24:30.100 Otherwise we end up sort of creating these dedicated 00:24:30.100 --> 00:24:34.289 coordinating objects like shipment manager. And an object like 00:24:34.289 --> 00:24:38.360 shipment manager doesn't represent a real-world entity and just 00:24:38.360 --> 00:24:43.730 adds conceptual noise to our domain model. 00:24:43.730 --> 00:24:47.210 So with this in mind, we assign this ship 00:24:47.210 --> 00:24:50.039 service to the order, so it can respond to 00:24:50.039 --> 00:24:54.630 that business request. And the service becomes an object 00:24:54.630 --> 00:24:57.960 factory for the shipment. And this is a pat, 00:24:57.960 --> 00:25:02.010 and follows the pattern of services becoming object factories 00:25:02.010 --> 00:25:06.100 for events. 00:25:06.100 --> 00:25:07.860 And here we come to our last skill, in 00:25:07.860 --> 00:25:11.299 terms of assigning attributes. And we've already taken a 00:25:11.299 --> 00:25:15.650 look at some attributes. These attributes respond to what 00:25:15.650 --> 00:25:17.620 I know. 00:25:17.620 --> 00:25:19.910 So coming back to our vehicle and our vehicle 00:25:19.910 --> 00:25:24.549 make, a vehicle with its registration number is a 00:25:24.549 --> 00:25:28.880 descriptive or tacking attribute, which is typical of a 00:25:28.880 --> 00:25:32.059 PPT. With the vehicle make we have these two 00:25:32.059 --> 00:25:37.260 descriptive attributes of a, of the model and the 00:25:37.260 --> 00:25:38.539 year. 00:25:38.539 --> 00:25:41.200 From our order example, again, we, for the order 00:25:41.200 --> 00:25:43.720 it has this tracking attribute of a number. It 00:25:43.720 --> 00:25:46.880 knows its state and it has this time stamp 00:25:46.880 --> 00:25:50.669 that's, that point in time events have. 00:25:50.669 --> 00:25:56.039 Now, Jill Nicola, in her book Streamlined Object Modeling, 00:25:56.039 --> 00:25:59.730 has identified six types of attributes. I won't go 00:25:59.730 --> 00:26:02.100 through all six, but you can see some examples 00:26:02.100 --> 00:26:03.919 on the right hand side there. 00:26:03.919 --> 00:26:07.380 I'll focus on two attributes. The life cycle state 00:26:07.380 --> 00:26:11.460 and the operating state. The life cycle state is 00:26:11.460 --> 00:26:15.850 a, is a one-way state transition. So an order 00:26:15.850 --> 00:26:19.940 would transition from pending to paid to complete, but 00:26:19.940 --> 00:26:22.530 it won't revert back to that stage. 00:26:22.530 --> 00:26:26.539 An operating stage is a state that switches back 00:26:26.539 --> 00:26:30.000 and forth between two states. So an example here 00:26:30.000 --> 00:26:32.110 is a product could be active, so active in 00:26:32.110 --> 00:26:34.830 a, in a catalog. We could switch that off 00:26:34.830 --> 00:26:38.610 and it wouldn't appear, appear in the catalog anymore. 00:26:38.610 --> 00:26:40.090 And then we could switch it on. So it 00:26:40.090 --> 00:26:45.250 switches back and forth. 00:26:45.250 --> 00:26:47.580 So now that you've been introduced to the five 00:26:47.580 --> 00:26:51.520 basic skills of object modeling, we have a set 00:26:51.520 --> 00:26:54.789 of skills to bridge this gap between your user 00:26:54.789 --> 00:26:59.910 stories and your Rails application. You have a framework 00:26:59.910 --> 00:27:02.789 to explore business domains. 00:27:02.789 --> 00:27:07.270 So, I've simply given you an introduction here. And 00:27:07.270 --> 00:27:10.179 if this talk has resonated with you, you're probably 00:27:10.179 --> 00:27:13.549 hungry for more. So I've outlined these three steps 00:27:13.549 --> 00:27:15.860 to help get you started. 00:27:15.860 --> 00:27:19.700 First, I've created a dedicated blog post providing some 00:27:19.700 --> 00:27:24.130 online resources that, resources that you can read today. 00:27:24.130 --> 00:27:26.480 Plus links to the books that I talked about 00:27:26.480 --> 00:27:27.799 in this talk. 00:27:27.799 --> 00:27:32.900 Secondly, talk, share this with you team members. This 00:27:32.900 --> 00:27:35.600 idea of object modeling is awesome to use as 00:27:35.600 --> 00:27:38.130 an individual, but the real power is when you 00:27:38.130 --> 00:27:40.780 have this common language with your team mates, and 00:27:40.780 --> 00:27:43.590 collaborate with each other. 00:27:43.590 --> 00:27:45.600 And then the third step is buy some post-it 00:27:45.600 --> 00:27:50.330 notes. Post-it notes are an awesome collaboration tool and 00:27:50.330 --> 00:27:52.600 some, and a simple collaboration tool, and it makes 00:27:52.600 --> 00:27:57.120 this whole modeling fun. 00:27:57.120 --> 00:28:00.159 So the next time, when a team member asks 00:28:00.159 --> 00:28:04.320 you, how do I model this? Use archetypes to 00:28:04.320 --> 00:28:09.830 guide you in finding objects. Use color to visualize 00:28:09.830 --> 00:28:13.340 and collaborate with your team members. Use the presence 00:28:13.340 --> 00:28:16.780 of one object to suggest the presence of another 00:28:16.780 --> 00:28:21.780 and form collaborations. Use business rules to validate or 00:28:21.780 --> 00:28:27.400 govern these collaborations. Assign services to business objects to 00:28:27.400 --> 00:28:31.730 fulfill business requests. And use these skills to build 00:28:31.730 --> 00:28:35.840 a model that mirrors the business, enabling you to 00:28:35.840 --> 00:28:39.929 correctly and efficiently understand the domain. 00:28:39.929 --> 00:28:41.889 Thank you.