You can find all the code files used in this chapter on GitHub: https://github.com/Packt Publishing/Software-Architecture-with-Kotlin/tree/main/chapter-2

Software systems are not physical objects that we can easily see or touch. At their roots, they are instructions that are interpreted by a machine. So, we will need to visualize software systems in other ways.

The major purpose of visualizing software systems is to demonstrate how stakeholder concerns are addressed. There is usually a lengthy list of concerns. Each stakeholder usually has multiple concerns at various levels of abstraction. It is not possible to address all concerns from all angles in one visual representation.

The concept of View was introduced in the 1970s to describe software architecture. Since then, there have been numerous efforts to codify and standardize methods in describing software architecture. ISO/IEC/IEEE 42010:2022 is the current standard in specifying software architecture, by which the architectural concepts, structure, and language are defined.

In a View, only selected perspectives of software architecture...

A system is composed of many components and the interconnections among them. The ability to group and separate elements in the system has become a crucial factor in ensuring it is maintainable, reusable, and extendable. We are going to cover three fundamental concepts that will help us group and separate elements appropriately, namely separation of concerns, cohesiveness, and coupling.

Separation of concerns

Separation of concerns is a fundamental principle that we should apply in every corner of the system. It is a principle that advocates segregating the system into independent components and having each component address a specific concern. Separation of concerns aims at creating a system that is easier to maintain, reason, and update, and which can adapt to changes in requirements over time.

Let us take the following scenario as an example: the submission of a draft service exchange contract from a household’s browser...

The SOLID principles are a set of five software architecture principles that advocate for creating maintainable, understandable, flexible, and modular software. Though they were originally targeted at object-oriented software, the concepts behind them are useful and can be applied to systems other than object orientation.

These concepts were first introduced by Robert J. Martin in his Design Principles and Design Patterns paper in 2000. However, the SOLID acronym was introduced later by Michael Feathers.

The acronym SOLID stands for the following:

• Single Responsibility Principle (SRP)
• Open-Closed Principle (OCP)
• Liskov Substitution Principle (LSP)
• Interface Segregation Principle (ISP)
• Dependency Inversion Principle (DIP)

We will walk through each of them and use the concepts that we have covered for discussion.

SRP

The SRP states that a class should have one responsibility or concern, and only one. There is only one reason...

The Law of Demeter, or the principle of least knowledge, states that a software component should have limited knowledge about the inner details of other components. More specifically, a component should not know about the internal details of another component.

Let us say there is a function that returns the city in the address of a person:

class Person(val name: String, val address: Address) {
    fun getAddressCity(): String {
        return address.city
    }
}
class Address(val city: String)

The Person class directly accesses the city property inside the Address class. The Person class should not have this knowledge, as this is a violation of the Law of Demeter.

This creates a coupling between Person and Address. The coupling dictates that if the city property changes its data type, then both classes will need to change. It also means that the code change is bigger than...

You Ain’t Gonna Need It (YAGNI) is a principle that states that functionalities should not be implemented until they are needed. This principle came from Extreme Programming (XP) as an approach to improve software quality and respond to changing business requirements.

This principle is also related to the idea of minimalism in software development, which states that we should avoid unnecessary code and complexity in exchange for clean, easy-to-understand, and extensible software.

Another way to describe YAGNI is as the imperative to do the simplest thing that works. This is by no means an incomplete design or unfulfilled user requirement. It still promotes complete and functional software that satisfies user requirements with the simplest design available.

YAGNI aims at a few practices:

• Simple and lean code base: By implementing only what is necessary now, a lot of complexity can be avoided. As a result, the code base is simple...

We have covered the 4+1 architecture view model, as well as system quality attributes, separation of concerns, cohesiveness, coupling, the SOLID principles, and the Law of Demeter. We have demonstrated them with code examples. These demonstrated that adhering to these principles lets the code become modular, flexible, maintainable, extensible, and easy to understand.

We have also discussed the conflicting concepts of the YAGNI principle and future-proof architecture. We clarified what future-proofing is and how it is different from capacity planning.

In the next chapter, we will explore polymorphism and its alternative approaches.