00:00:05.500
Good morning! How many of you have read or heard of the book "Drawing on the Right Side of the Brain"? Okay, we've got a few people here. Excellent! For those who don't know, this book was authored by Betty Edwards, originally published in 1979, with a latest edition released in 1999. It argues that drawing is a talent that you are born with, but it is actually a skill that can be learned. One of these skills is viewing negative space—the idea that you draw the areas around objects rather than the objects themselves. This technique tricks the brain, switching it from a logical thinking mode to a more perceptual mode. The benefit of this is that when making decisions, we sometimes rely more on our perceptual skills rather than purely logical assessments.
For example, if you look at a chair, you'll notice its legs are quite thin. Logically, you might think, "If I sit on that chair, it won't hold my weight." This logical thinking could lead you to distort the image of the chair by making its legs thicker. Betty Edwards describes drawing as five foundational skills; a global skill made up of perceptual skills that allow you to understand what you've seen correctly and efficiently.
I am Nicholas Henry, and today I would like to introduce my talk "Modeling on the Right Side of the Brain," where I will share the five basic skills of object modeling. We will explore how to use color and patterns to help you visualize and communicate the key models involved, along with the five essential skills for object modeling: identifying objects, defining collaborations, understanding business rules, and assigning services and attributes.
00:01:45.490
First, let's clarify what a domain model is. We will review the scenario of shipping an order, commonly seen in an e-commerce setting. A domain essentially represents a business process. Let's consider a business request to ship an order, which is a business object. We will create a shipment—a different business object—that collaborates with the order in this process. However, we need to confirm that the order has been paid for before proceeding to ship it; otherwise, it wouldn’t make much business sense. Essentially, a business domain or domain model is a collection of business objects representing real-world entities, their collaborations, business rules, and the services responding to business requests.
Models, in this context, are representations that could be mental models—our understanding of how a business process functions—or graphical representations, such as the notation I'm using now. They can also be coded into models in your Rails application. When building an application, there are certainly additional concerns like persisting these business objects to a database or handling HTTP requests. However, these concerns lie outside your domain model; think of the domain model as the core of your application.
00:02:59.900
Now, when a business request comes in, we can utilize business services to respond. The word 'services' has been mentioned in prior discussions about domain-driven design, which is a practice that Rails developers have adopted. We create a service class to encapsulate logic for tasks such as sending emails or retrieving user records, with the aim of reducing the responsibilities of controllers. However, when I refer to services, I mean the idea of responding to a business request, which I will call 'business services' to distinguish them from regular service classes.
Why is object modeling important? It feels like there is a gap between user stories—great for gathering requirements from the end user’s perspective—and the implementation of models in our Rails applications. It’s almost as if we lack a tool to represent the underlying business model, identify objects representing real-world entities, and define the business rules governing their collaborations.
As Rails developers, we often discuss domains in terms of associations, using phrases like 'has many' or 'belongs to.' Object modeling and these five skills can help us bridge the gap between user stories and actual implementation.
00:05:01.490
Before proceeding, it’s important to set expectations. I will not be showing any code examples—thank you for not leaving! There will be plenty of talks over the next couple of days displaying various implementations. However, I believe that the practice of object modeling, which will be discussed now, is independent of implementation and is crucial for understanding the business model itself.
This practice is not new; Peter Coad first discussed it in his 1999 book 'Java Modeling and Color.' While this book may not be widely popular due to its content, other influential resources, like 'Streamlined Object Modeling' by Jill Nicola, have significantly influenced how I approach understanding a business domain.
What I appreciate about object modeling is that it provides a framework similar to how Rails gives us guidance on structuring applications. It offers conventions and helps accelerate web development. Object modeling enables us to visualize and discuss domains, facilitating a better understanding of business domains, but it is not endorsing any large upfront design. Rather, it is a tool for sketching ideas, collaborating with team members, and guiding implementation.
00:06:37.160
In this talk, the diagrams will utilize Unified Modeling Language (UML) notation as communication tools. The goal with these diagrams is not the diagrams themselves but how they help facilitate understanding of the domain. As object modelers, our primary building blocks are the objects themselves.
Working in an object-oriented language, when I speak about objects, I'm going to do so in the first person to personify them. Objects fulfill three responsibilities: 'Who I am,' 'What I do,' and 'What I know.' For example, an order object would know its order number, its state, the timestamp of its purchase, and it would also know its collaborators, such as the shipment, and how to ship itself via its business service.
00:08:10.640
Now that we have this building block established, let’s talk about our first skill: finding objects. A common mistake with finding objects is viewing business objects as unique, like little snowflakes. In reality, we can group objects with similar responsibilities into categories. These groups are referred to as archetypes, as designated by Peter Coad. There are four archetypes: events, roles, parties, and things—often summarized as PPTs.
Let's examine the first archetype: events. Events are modeled as transactions within our domain and are crucial business objects. They serve as the glue that holds other objects in the business domain together. Without events, I would argue that the application reduces to a mere catalog application. In an e-commerce domain, examples of such events would include orders and shipments; in a hotel reservation system, reservations would fall under this category as events.
We recognize two types of event archetypes: a point in time and an interval. A point-in-time event has a single timestamp, such as the purchase date of an order. In contrast, an interval archetype for reservations includes two timestamps—check-in and check-out dates.
00:09:33.680
Rules within the domain model do not exist in isolation; they form the connections and interactions among various objects. We use roles to illustrate how an object participates in an event. For example, in our domain model, a customer might play the role of a buyer for an order, while a fulfillment provider could serve as the role associated with the shipment process.
Continuing with roles, we need to reference actors—parties in the domain, represented by our PPTs. A party can refer to either a person or organization, while 'place' might denote a warehouse in a shipping context, and 'things' are generally paraphernalia related to the product at hand.
Additionally, we have the final archetype: the description object. Descriptions provide details about a collection of similar objects, such as product categories, which aggregate types of products, like T-shirts or jeans on an e-commerce site.
Description objects can sometimes be challenging to grasp, so I'll explain this further while discussing identifying collaborations.
00:11:10.730
During collaboration, as soon as we add a few business objects to a diagram, it can become increasingly complex to navigate. Don't worry—you're not expected to read every detail! I just want to illustrate a point. To solve this complexity, consider adding color to provide an additional layer of information. Were you able to notice the color changes of my slides when discussing the archetypes? For example, the event archetype was represented by pink or red, which highlights activity in the domain model. We will use yellow for roles, green for PPTs, and blue for descriptions. By incorporating this color coding into your domain model diagrams, you can quickly identify activity hotspots, such as the events and the objects interacting with them.
00:12:13.850
Moreover, this color coding serves as a collaborative tool. You can utilize post-it notes corresponding to these colored archetypes on a whiteboard with your team, facilitating an agile environment for discussing the business domain. With these four archetypes, we can effectively find business objects in our domain. However, as we’ve noticed, there can be challenges in discussing an individual object in isolation, which leads us to our next skill: identifying collaborations.
Let's first differentiate between associations and collaborations. As Rails developers, we are familiar with associations from Active Record, but associations typically imply a passive relationship. In contrast, collaborations suggest an active relationship characterized by dialogue—a key aspect for discussing business rules. Therefore, going forward, I will use the term collaborations to describe the interactions between objects.
00:13:55.540
When identifying collaborations, we focus on an object's responsibility of 'Who I know.' Frequently, we might think about objects in isolation, such as a customer or an order. However, the presence of one business object usually indicates the presence of another. This principle is emphasized by what I have termed the elementary collaboration pattern.
For instance, when we have an event, we recognize that a role is required to interact with that event. If we know there are roles, we need to identify the actor—which are our PPTs. For example, if we have a collection of PPTs, we may need a description of that collection. This framework essentially serves as a template, which can be adapted as necessary.
If a PPT only engages in one event, it is advisable not to create a dedicated role for it, as this would complicate your object model. Let's consider an example of a person interacting with an order; they could either be a customer making a purchase or a sales agent confirming that sale. It’s imperative here that the same individual cannot occupy both roles at once.
00:15:56.280
In illustrating roles, we can introduce multiplicity rules, where the number next to the customer indicates that an order belongs to one customer, while a customer can belong to many orders. We can represent the presence of description PPTs in comparison to the descriptions themselves. For example, imagine a vehicle identified by a unique registration number and defined by attributes like its make and model and the year of manufacture. Let's clarify this by considering examples of vehicles represented by their unique registration numbers but highlighting how we can improve our model by avoiding duplicate attributes in our descriptions.
For instance, instances of vehicles should streamline data such that rather than having repeated attributes regarding model and year for each registration number, we can represent the vehicle attributes through a description object. Such an approach helps in normalizing our data effectively.
00:17:07.810
Furthermore, archetypes can interact with others of the same kind. For example, an event archetype can collaborate with another event archetype, illustrated through the patterns like composite and follow-up interactions. The composite collaboration pattern illustrates how one event is composed of other events. For instance, in a transactional scenario, we would discuss an order and its line items. This introduces UML notation, where a solid diamond signifies a composite relationship in the model. Conversely, follow-up transactions depict connections like an order followed by a shipment.
Let's visualize this further with a detailed example: a product description interacting with an order line item, showing how products are linked to their respective orders. This relationship also extends to shipments and line items—a composite collaboration where each order's line item corresponds to related shipments.
00:18:32.330
Building upon previous discussions of business object collaboration, we can leverage these patterns as foundational blocks in our domains. Now, let’s address business rules. These rules dictate how collaborations function, specifying whether they conform to established policies or external regulations, like laws set by governments.
Often when thinking about these rules, we narrow the focus down to validation rules, which check for specific conditions like email format. However, business rules extend beyond this by governing and validating collaborations. For instance, both the shipment and shipping method must agree on specific criteria to validate their collaboration, such as the weight of the shipment relative to the shipping method’s limits.
00:20:22.290
To clarify how partnerships govern collaborations, consider the example of a shipment collaborating with a shipping method. The shipment has a total weight, which could trigger expedited handling. Meanwhile, the shipping method imposes a maximum weight constraint. This dynamic highlights that the shipment and shipping method must work together to establish whether they can collaborate, outlining conditions for validation.
00:22:17.760
This brings us to our fourth skill, which is assigning services. Services pertain to the responsibilities of 'What I do.' Business services exist to answer business requests, forming and dissolving collaborations and creating new event objects. Although services can also update attributes, today I'll focus on their role in facilitating collaborations.
Recalling the earlier scenario of shipping an order, visualizing how the order responds to incoming requests while checking the business rule of confirming payment. Once verified, the order can proceed and create a shipment as a result of the collaboration.
00:24:32.780
One challenge within object modeling is that while real-world entities tend to act actively, in object modeling, the objects themselves must perform the actions. For instance, an order will ship itself. This approach allows for denser encapsulation of information, as everything needed for the action lies within the object. We want to minimize the creation of intermediary objects, such as a 'shipment manager', which detract from the conceptual clarity of our model. Instead, we let the order invoke a service and collaborate to create a shipment, enhancing the accuracy of representing real-world activities.
00:27:16.910
Next, we delve into our final skill, assigning attributes. We’ve touched on some attributes earlier—those that describe 'What I know.' For example, a vehicle's registration number and its characteristics like model and year are crucial attributes. Similarly, in the order example, attributes such as order number and timestamp taxes help clarify the state of the order. Attributes play vital roles in representing lifecycle stages: those that transition once, like an order going from pending to complete, versus operating states that may fluctuate, like a product's availability in a catalog.
00:29:07.080
Having introduced the five basic skills of object modeling, these form a toolkit to bridge the gap between user stories and your Rails applications. You now have frameworks to explore business domains and gain insights. This introductory talk should spark interest if you wish to delve deeper. I've outlined three steps to help get you started. First, I have written a dedicated blog post listing online resources and explaining the concepts discussed.
00:29:50.240
Second, share this information with your teammates. While understanding object modeling is important on an individual level, its true power lies in fostering a common language within your team and collaborative efforts. Finally, utilize post-it notes; they are excellent tools for collaboration that can inject fun into this modeling process.
So the next time a team member asks how to model a concept, use archetypes to guide identifying objects, employ colors to visualize structure, and collaborate with your teammates. Recognize that the presence of one object suggests the presence of another to form collaborations, while business rules surround these interactions and shape the relevant services to fulfill requests. By applying these skills, you can effectively model your domain, ensuring an efficient understanding of your business.
