The evolution of software design units—from Objects to Microservices—is not merely a shift in coding practices. It represents a continuous journey to answer a fundamental question: how can humans effectively control large and complex systems?

In this article, we explore this evolution by drawing an analogy to how a small startup grows into a global enterprise, reflecting the progression of modeling techniques.

1. The OOAD Era: Direct Communication Among Passionate Individuals (Object-Based)

In the early days of OOAD (Object-Oriented Analysis and Design), organizations resembled small teams where every member clearly understood their roles and responsibilities (R&R) and worked in close coordination.

At this stage, the smallest unit of software was the object, and all objects existed within a single container—like employees working in one building.

Team members communicated directly, calling out to colleagues sitting nearby. They shared data and functionality efficiently, enabling quick decision-making and execution.

However, as the organization grew beyond 100 people, chaos began to emerge. Leadership struggled to track who had what expertise or who was underperforming. Communication paths became tangled, and the cost of coordination started to outweigh productivity.

With too many individual units in a single physical space, even small changes could disrupt the entire system, leading to inefficiencies.

2. The CBD Era: Introducing Departments and Specialization (Component-Based)

To overcome these limitations, organizations adopted CBD (Component-Based Development).

This introduced the concept of departments, grouping related objects into cohesive units called components. Teams such as HR, Finance, and Engineering were formed with clear boundaries and internal hierarchies.

Instead of managing 100 individuals, leadership could now manage around 10 department heads. The organization became more structured, and each department developed domain expertise, functioning like reusable components.

However, challenges remained. Collaboration across departments still relied heavily on face-to-face communication—walking to another office or scheduling meetings.

While structural boundaries were defined, communication was still tied to a physical headquarters.

3. The SOA Era: Online Networks and the Birth of Services (Service-Based)

As organizations grew to 200 members and operations became more complex, the inefficiencies of physical communication became unacceptable.

This led to the adoption of SOA (Service-Oriented Architecture).

Each department was equipped with a standardized communication mechanism—analogous to installing “standard telephones” (RESTful APIs). All inter-department communication was required to go through these standardized interfaces.

Departments evolved into services, exposing functionalities that could be invoked externally.

Now, employees no longer needed to physically visit another department. They could request tasks remotely through well-defined interfaces and receive responses in real time.

Despite this advancement, a critical limitation remained: everything still operated within a single headquarters (a single container). If the central infrastructure failed—such as a server outage or power failure—all services across the organization would stop simultaneously. This created a significant structural vulnerability.

4. The MSA Era: Independent Operations and Fully Distributed Offices (Microservices-Based)

As the organization expanded beyond 300 members, the inefficiencies and risks of a centralized structure became too significant to ignore.

This led to the adoption of MSA (Microservices Architecture).

The organization was decomposed into independent, distributed units, similar to separate branch offices or business divisions.

Each unit—now a microservice—operates like a small independent company, with its own infrastructure, operational rules, and autonomy.

For example:

• Customers in Seoul are handled by the Gangnam branch
• Regional customers are served by local offices

Even if one branch encounters issues (e.g., a fire), other branches continue operating without disruption.

This marks the evolution:

• From individuals (objects),
• To departments (components),
• To connected services (SOA),
• And finally to fully distributed, autonomous systems (MSA)

This progression clearly demonstrates a key engineering principle:

as systems scale, coupling must decrease while independence increases.

From this perspective, MSA is not just a trend—it is the inevitable organizational design chosen by large systems to eliminate inefficiency and survive complexity.

5. The Unchanging Essence: The Root of All Evolution Lies in Objects

So far, we have explored the structural evolution—from objects to components, services, and microservices.

While the external architecture has drastically changed, the core remains the same:

the object.

• Components are collections of collaborating objects
• Services and microservices are also composed of interacting objects

Architectural evolution is essentially about:

• Aggregation: grouping objects into larger units
• Encapsulation: defining boundaries and isolating them

At its core, it is still about how objects collaborate.

In her work, Rebecca Wirfs-Brock defined objects not merely as data holders, but as active entities that perform roles within a system.

She categorized object roles as follows:

Object Role Stereotypes

1. Information Holder: Maintains and provides necessary data
2. Structurer: Organizes relationships and system structure
3. Service Provider: Performs specific tasks or computations
4. Coordinator: Manages interactions and workflow between objects
5. Controller: Detects state changes and makes decisions
6. Interfacer: Communicates with external systems or users

Within any microservice, these types of objects collaborate to deliver functionality.

Conclusion

Designing a robust microservice is ultimately about assigning appropriate roles and responsibilities to the objects within it and enabling effective collaboration.

Even in large-scale distributed systems, the real value is created by individual components—just like skilled employees within an organization.

Although software architecture appears to evolve from OOAD to components and microservices, the foundation remains unchanged:

object modeling.

When we clearly define object responsibilities and design their interactions effectively, we can build components, services, and microservices that are both scalable and resilient.

No matter how much technology evolves, the essence of software modeling still lies in the object.

doitsong