第2章計算論的思考と設計の再利用性

Imagine an online store called SwiftShop. They had a problem. Even though they had lots of great products to buy, people were leaving their website without buying anything. It was like having a store full of customers who walked in and out without buying anything! The business challenge is SwiftShop wanted to make shopping on their website easier and more fun. They wanted people to stay longer, buy more, and come back again and again. SwiftShop decided to use smart design tricks to fix their website and make it super easy to shop. Here’s how they did it:

• User interface (UI) design patterns: Breadcrumb navigation: SwiftShop added breadcrumb trails so shoppers could easily see where they were on the website and find their way back if they got lost.

• Progress indicators: During checkout, SwiftShop put in progress bars so shoppers knew how far along they were in the buying process.

• Information architecture (IA) design patterns: Card sorting: SwiftShop asked real shoppers to help organize their products. By sorting cards and asking people how they’d group things, SwiftShop made it easier to find what customers were looking for.

• Faceted search: SwiftShop added filters so shoppers could narrow down their searches by attributes like price, size, and brand.

• Interaction design (IxD) patterns: One-click purchase: To speed up the buying process, SwiftShop let registered users buy with just one click.

• Personalized recommendations: SwiftShop used machine learning algorithms to suggest products that customers might like based on what they’ve bought before.

• Results: After making these changes, SwiftShop saw great results:

◦ More people buying: With the new features, more people ended up buying products from SwiftShop.

◦ Happier shoppers: Customers spent more time on the website, which meant they liked shopping there more.

◦ More repeat customers: Because it was easier to shop, people kept coming back to SwiftShop again and again.

So, by using smart design tricks like breadcrumb navigation, progress indicators, card sorting, faceted search, one-click purchase, and personalized recommendations, SwiftShop made their online store a better place to shop.

Two heuristics are inherent to the design of business solutions and the creation of business solution architectures. These heuristics are known as layering and componentization and can be thought of as design approaches followed with an intent of architectural concerns.

Componentization has already been introduced as a computational thinking and adaptive design reuse technique.¹ Layering in business solution architecture involves creating distinct layers that abstract specific aspects of the overall architecture. This heuristic enables the separation of concerns between layers and improves modularity. Each layer comprises components, and a layer may consist of multiple components. This hierarchical structure helps organize and separate different functionalities or responsibilities within the architecture, making it easier to manage and understand.

The layering strategy is based on the concept of separating different concerns. This method structures software design into distinct, stacked layers, with each layer tasked with specific functions. Commonly, business solution architectures are organized into three main layers: the presentation, business logic, and data management layers. The presentation layer is the user’s touchpoint, handling the user interface (UI) and delivering the user experience (UX), which is the overall experience that a person has when interacting with a product, service, or system. The business logic layer holds the business logic for the business solution or application, separating the UI/UX from the business-centric computations. This separation affords the flexibility to adjust business operations as needs evolve without disrupting other system components. Although not tied to a specific domain, the data management layer is responsible for interacting with persistent storage systems like databases and various data processing mechanisms. In a layered architecture, information and commands flow through each layer, enhancing the design’s abstraction level, which denotes the granularity or detail at which a system is represented. Despite its structured approach and abstraction benefits, software designed in this layered manner might lean toward a monolithic build, potentially making modifications challenging. Layered architecture can lead to tightly connected layers in software, making it difficult to change one part without affecting others. This tight connection can also make it harder to update or expand the software.

A monolithic structure is a type of system or application where all the parts are closely combined into one single unit. This setup means that everything from the user interface to data handling and processing is interconnected within one big software application. While this can make the system easier to set up and manage initially, it also means that changing one part can require changes throughout the whole system, making it less flexible. As illustrated in Figure 2.10, there are many more recent variations of layered architectures that also provide complementary capabilities, such as tiered architectures, service-oriented architectures (SOA), and microservices architectures.²

1 Componentization was used initially in component-based business solution architectures that were derived from the Object Management Group’s Object Management Architecture (OMA), including CORBA 3, JEE, DCOM, and COM+. 2 Per an article written by Thoughtworks Martin Fowler in 2014, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

Detailed coverage of these specific architectures is not part of the scope of this chapter. They will be discussed in more detail in multiple later chapters. It’s fundamental to understand that each software architecture model is crafted to address the key challenges found in its preceding models. Being well-versed in various architectural approaches equips you to devise a robust and effective architecture for your specific project. While no software architecture can claim absolute perfection, an approach can be deemed highly suitable or “relatively perfect” if it aligns well with the specific requirements and goals of your current project.