00:00:09.599
As the next speaker, Mi Miow has spoken at multiple meetups in different cities. He has spoken on webinars and written multiple articles, but this is his first time on a bigger stage. So good luck to Miow, and let's give a big shout for him.
00:00:28.640
Hello, is this one better? Okay, Maros introduced me, so let's keep this part. I think I want to start my presentation by assessing your capability of gathering knowledge from what I am about to present.
00:00:41.280
Let me ask you a few questions first. How many people have worked today? Please raise your hands. Okay, about half. And how many people came to this conference from a different city or country? Quite a lot. Now, how many people are going to the after-party? Nice! I see a correlation between not working and going to the after-party, so that's good.
00:01:11.799
My presentation is a little academic, but I will try to make it as easy to capture as possible for you. Let me start with a question: have you ever felt that when you started designing a solution or architecture for some feature, someone had already done something similar? Maybe that was a rhetorical question, but thank you.
00:01:30.920
Or perhaps you felt internally that you had already solved a similar problem in another application. Of course, some requirements were different, but the problem was basically the same. If you have had this feeling, my presentation tries to address it, and I will show you some solutions that people have applied to those problems.
00:01:58.319
Here is the bad news: my presentation is based on a very complex and sophisticated book written about 20 years ago. I highly recommend reading this book if you want to become a software architect or if you have sleep problems. I studied this book for the last six months, and this presentation will summarize its core points.
00:02:20.920
Let's start with some definitions. There is a word 'archetype' in the title of my presentation, and throughout this talk, it will be mentioned numerous times. So, what is an archetype? This guy here is Carl Gustaf Jung, who authored the definition of the word 'archetype.' Of course, this word was used long before him, but let's stick to the definition he crafted.
00:02:44.560
Jung's definition states that there exist some universal concepts across human cultures and groups. For example, one of those universal concepts is the idea of being a hero. It doesn't matter if you ask people in ancient Greece, medieval France, or even a hunter from an Apache tribe; they all know what it means to be a hero.
00:03:06.920
There are some common traits that you need to have to be a hero: you need to be brave and skilled, and you must overcome challenges. This notion of a hero demonstrates that some people fit the description while others do not.
00:03:26.320
Why is this important for us? Because we usually work for businesses, creating software systems that serve businesses. There exist archetypes in businesses that you are likely already familiar with—ideas such as a customer, a company, inventory, or a product your company is selling.
00:03:46.320
What is useful for us is that these archetypes can be grouped together and described as patterns. In the context of the book I'm referencing and my presentation, when we talk about an archetype, we mean a specified requirement and a way to meet those requirements.
00:04:06.760
If you change those requirements, it might turn out that the pattern won't be applicable, or only parts of the pattern will be applicable. So how do you gain knowledge about archetypes? Obviously, besides my presentation, you can read more books and articles or talk to experts.
00:04:26.640
For instance, if you speak with an accountant who has worked in business for 20 years, he or she already knows a lot about archetypes that exist in various companies. Additionally, if you are working on software systems that solve some problems, you can gather knowledge about archetypes from those systems.
00:04:51.800
Now, there is a term called pleomorphism, which comes from biology and means adapting to an environment to survive. In the context of software engineering, it refers to adapting an archetype or theory that comes from an archetype to your specific use case. We will use this term because it signifies that you have an archetype and need to adjust it to meet your specific requirements.
00:05:16.640
A basic recipe for using these archetypes is as follows: when you have knowledge about archetypes and what you need to do, you must select the parts of the archetype that fit your problem and meet your requirements.
00:05:36.000
You will see later on in my presentation that those archetypes are usually represented in UML diagrams. You can integrate them into your code through translation or mapping, meaning you take those UML diagrams and transform them into your Ruby classes, models, and modules.
00:05:56.320
However, there is no universal solution for every problem. Most likely, your business and its challenges are somewhat unique. Therefore, you might need to extend the archetype with elements that are missing.
00:06:16.560
Equipped with this theoretical knowledge, we can start discussing examples. One key point: when I mention 'party,' it's not what you might initially think.
00:06:31.040
Typically, when we talk about a party, we think of a birthday or after-party where people are having fun. However, during this presentation, we will use it in a completely different context, which you might know from tabletop games: you must gather your party before venturing forth. Here, 'party' refers to a group of people or the side of a relationship.
00:06:54.239
In business terms, it describes someone or something with which your business is working or cooperating. I mentioned that UML diagrams are present in archetype descriptions.
00:07:12.240
Unfortunately, I have a few UML diagrams to show in my presentation, but the good news is that we will go through them quickly. They are merely to demonstrate how they look. If you want to study them, you can find them on the internet or in the book.
00:07:33.960
What’s important about these UML diagrams is that a 'party' is usually implemented as either a person or an organization. In other words, it can be a human being or a company structure.
00:07:52.440
These are the two core elements of the party archetype. But there are more aspects to consider. Most likely, you have a user class or user model in your Ruby on Rails application.
00:08:12.480
The first challenge arises in how to identify parties uniquely. In Rails, this is usually sorted out by using IDs in your database, which is perfectly fine. However, you can also have registered identifiers from third-party applications. For example, you could use a passport number or Social Security number for people or a registration number for companies.
00:08:33.520
Yet, we need to be aware of some limitations associated with these identifiers. Additionally, there are other elements I will briefly cover.
00:08:52.240
We also have party signatures, which help identify that a particular party executed an action within the system. Other attributes of parties include their names, addresses, and references.
00:09:13.920
The book indicates that if you need to capture names in greater detail, you could use ten different attributes. We also have a party manager responsible for handling parties, finding them in your system, and managing signatures.
00:09:34.720
As you can see, the party archetype is relatively straightforward: we usually have a user class or user model in our applications, and it functions well. However, the more complex challenge is how parties can connect in various ways.
00:09:53.800
The next archetype addresses this fact, and this is likely the most important slide related to the party relationship archetype. Imagine we have a relationship between two parties: one is a father and the other is a son.
00:10:13.120
We can describe this relationship at different levels of abstraction. For example, we can say this is a father-son relationship, which is quite detailed. Alternatively, we can describe it as simply a parent-child relationship, or even more generally, as a family relationship.
00:10:32.080
The last example is quite abstract and symmetrical because it doesn't specify who is who in this relationship. On the other hand, 'father and son' explicitly indicates the roles within this relationship.
00:10:47.280
This distinction is crucial; when implementing party relationships in your system, you need to decide on the level of abstraction at which you want to capture this relationship.
00:11:08.400
You can choose to be detailed or general, but that decision must be made. If you don't know this archetype well, you're likely to make that decision randomly.
00:11:30.880
The book suggests that if you're capturing symmetrical relationships, it might be less beneficial for your business. Asymmetrical relationships capture more information that might be crucial to your operations.
00:11:52.079
Using this archetype makes much more sense for asymmetrical relationships because differences between roles often lead to more valuable insights.
00:12:11.120
The party relationship archetype can lead to additional complexities, where siblings, for instance, can hold distinct roles—like being a brother and a sister. This adjustment accentuates the need to specify how one party differs from another.
00:12:33.200
One way to do this is by naming one party a supplier and the other a client. This is somewhat arbitrary; in certain relationships, this designation makes sense, while in others, it might not.
00:12:55.400
Moreover, having defined roles can facilitate storing additional information rather than keeping it in the base models. You could separate roles and relationship types into distinct models, which provides more flexibility.
00:13:17.440
When you have party relationships and roles, you will soon realize that your system must address specific questions. For instance, can one party play a specific role in a given relationship, or can two parties be connected? To address this, we have models like role constraints and relationship constraints.
00:13:37.600
Furthermore, if a party is playing a role, there might be responsibilities associated with it, which could dictate what that party is allowed to do.
00:13:59.840
Eventually, as you develop your model of relationships and roles, you may want to introduce a party summary. Other parts of the system may only need to capture the essence of information about specific parties.
00:14:18.920
Here’s a recap: if you plan to use this archetype, it’s quite intuitive. You start by defining parties, then model relationships between them. It's advisable to check if the relationships meet business requirements regarding symmetry.
00:14:44.480
Once established, you assign roles for each party in each relationship and can add elements such as constraints, types, and responsibilities if needed.
00:15:02.720
If you are not planning to utilize this archetype, that’s also acceptable. The real benefit of archetypes is that they prompt you to consider questions and challenges you may need to address.
00:15:23.360
Some of these questions include: what relationships between parties do you need to capture? What levels of abstraction will you use? How symmetrical should those relationships be?
00:15:44.360
The archetype discourse also addresses how you will manage the roles and which parts of your system will determine whether two parties can be connected.
00:16:07.040
Now, you may be wondering where the code or Ruby on Rails examples are. I have a repository with examples of the party relationship archetype, and I encourage you to check it out.
00:16:28.800
You can see that UML diagrams from the archetype can be translated by creating equivalent models in your Ruby on Rails application.
00:16:48.080
After implementing these ideas in Rails, I have some reflections. One key takeaway is that we often capture only the existence of a relationship rather than the characteristics of that relationship.
00:17:14.080
For instance, when using a join table for a has-many-through relationship, we only capture that two entities are linked but not the characteristics of that connection.
00:17:30.320
We usually think of relationships in terms of Active Record, with its convenient API that beautifully models the relationships between models: has many, belongs to, and so on.
00:17:52.080
This can make implementing the approach proposed by archetypes feel unintuitive. Additionally, searching through these relationships can also be complicated.
00:18:08.720
One party might not be directly connected to another, as the relationship is defined through a role connecting one party to another, adding layers to the search process and increasing complexity.
00:18:30.000
Conversely, this archetype is quite valuable if you have strict rules on how to connect relationships, especially if you find that your system requires added columns to join tables. This could mean extracting them into separate models makes sense.
00:18:51.680
Now, let’s look at another archetype, which pertains to products. Most likely your business sells something, so your system must handle these products. The product archetype encompasses the goods or services your business sells.
00:19:12.000
The crucial thing to understand is that there are different types of products to consider. Too often, we tend to optimize our systems for only one type, but this could be a mistake. We should optimize for all types if we anticipate the growth of our business.
00:19:30.720
What are those product categories? For instance, identical products are mass-produced items, such as a bottle of water. There are also unique products, often artisan-made items that are singular in nature.
00:19:52.960
Then, there's a middle ground: identifiable products that might involve creating multiple versions of a product, each slightly different, like an artist who creates 20 copies of a unique painting.
00:20:13.440
Deciding which types of products your system will support should be an informed decision rather than a mere assumption that a product table will suffice.
00:20:32.240
The archetype suggests having a distinction between product types and product instances, which are two perspectives on what is being sold. Product instances refer to specific items being sold, while product types denote general categories seen in catalogs.
00:20:52.040
Normally, product instances are identified using serial numbers, while product types are identified by product identifiers. Additionally, products may need to be grouped into batches, especially if they are manufactured together.
00:21:11.440
It's important to capture this information effectively. Moreover, product specifications that require more detailed attributes should not just be nested within the product type but stored distinctly.
00:21:35.120
The archetype discusses catalogs and searching for products, suggesting that the information users search for might not directly align with what is available in inventory.
00:21:57.840
Catalog entries might not be one-to-one with product types, for instance, when cataloging medicines. A catalog entry for a specific medicine, like aspirin, may not correlate directly with all its production attributes.
00:22:16.400
Additionally, as you maintain a catalog, enabling efficient searching is essential, considering customers may utilize different search terms.
00:22:37.640
When products are combined into packages, the archetype also addresses various questions, such as how to manage pricing for products within a package and the types of packages available.
00:22:58.240
The archetype clarifies that pricing management should occur in isolation from the product type or instance, as prices can change over time.
00:23:17.920
If you're not using this archetype, it's helpful to note that it raises awareness of challenges, such as product identification techniques—be it your system's unique identifiers or international standards.
00:23:36.320
It also highlights considerations for how you will connect serial numbers to product batches, as well as the needs of effective searching capabilities, especially if you're using systems such as ElasticSearch.
00:23:58.720
Product packaging introduces its own challenges, such as how to deal with promotions and expected changes to pricing. In my repository, I have examples of product and product types that you can review.
00:24:16.080
In conclusion, one of the most valuable lessons from this archetype is the distinction between product type and product instance. It reinforces how crucial it is to model your application based on the exact types of products you are looking to sell.
00:24:38.720
Moreover, when you delve deeper into archetypes, you will recognize that there is a specific version of an archetype for every product type or a more generalized version for multiple types, which is notably more complex.
00:25:00.360
Finally, understand that inventory management and what is recorded in your catalog might differ from what exists in your warehouse, especially regarding pricing adjustments.
00:25:22.000
There are more archetypes available, like inventory archetypes that clarify product availability, order archetypes, rule archetypes that offer flexibility for numerous rules, and even CRM archetypes.
00:25:45.200
To summarize, even if you are not planning to implement archetypes, understanding them can still provide significant value. They highlight potential problems you may face and help direct your thinking towards workable solutions.
00:26:11.000
Importantly, you can selectively utilize elements of archetypes instead of implementing them entirely. They can inspire you to devise tailored solutions.
00:26:32.079
Finally, consider exploring the available literature on this topic. The core concepts remain largely the same, even if the naming conventions differ, whether referred to as object models or archetypes.
00:26:57.120
Thank you.
00:27:22.080
If there are any questions, feel free to ask!
00:27:33.520
Hi, great presentation! My question would be: is there another level of abstraction that helps you transition between archetype levels or provides recipes for increasing the relationship layer?
00:27:55.440
If you could provide steps for transitioning from a more abstract level to a more precise one?
00:28:14.320
I think what you're asking about is in the translation or mapping steps mentioned previously. The book suggests taking the UML diagrams and figuring out how they relate to what you currently have.
00:28:33.760
One class from a UML diagram might translate into three classes in your system. You must approach archetypes as a target point.
00:28:55.200
Any other questions?
00:29:17.440
Thank you so much for your insights.