The new view of app architecture

Hi there!
This article is inspired by the book “Perfect Software” by Juvel Levee

The author proposed a new concept for software architecture. The name of the new concept is the Method. The method is software design + planning. In this particular article, we are going to concentrate only on the design part, not planning.

It’s hard to change architecture when we are already ready to market stage — hard and expensive to change software architecture. Sometimes companies and employees rush to finish some jobs to deploy solutions to the market.

Okay, now let’s talk about how to avoid crunches by using the Method

Most architectures that I have seen were based on functional decomposition. The functional decomposition divide system into structural elements, which are responsible for some functions of the system. For example, if the system has to do some operations like billing, payment, and goods shipping — you will have Billing service, Payment service, and Shipping Service.

Cons of functional decomposition

The functional decomposition has a lot of cons. At least function decomposition connects services with requirements because services are mirror requirements. Any changes at required functionality will cause service changes. These types of changes will happen in the future. It will cost a lot of time and money for change to mirror new requirements. One more thing the functional decomposition doesn’t allow you to reuse your service in other projects.

Barries to reuse

For example, let’s take a look at the simple system with the functional decomposition. We have three services — A, B, and C. The are interact in this way

As the functional decomposition is the same as decomposition by time, it is an obstacle to reusing any of these services in other systems. For example, other systems need to use Service B (aka Billing Service). the concept of what is called after A, but before C is built into the basis of the service. Any tries to reuse Service B in other systems will be failed. When service B is migrated, services A and B are bound to it. B is not an independent reusable service — A, B, C form a conglomerate of closely related services

Too many or too few

One of the methods to do functional decomposition — is the creation of a service for all types of functionality. This method of functional decomposition will produce a huge number of services. This will cause a lot of code duplication around the service's codebase.

The other method is to create a mega-service. The one service can do a lot of stuff. It will cause a lot of time and money to maintain this service.

Anti-design

Convincing colleagues and management to use something else instead of functional decomposition is a very difficult task. There are two objections to this argument. First, you can answer: “And how many times have we met the deadline or budget that was originally approved? What did we get with quality and complexity? How easy was it to maintain the system?”

Second, you can have an anti-design session. Let the team know that you are hosting a next-generation system design competition. Divide the team into two halves and seat them in different rooms. Invite the first half to come up with the best design solution for the system. Then ask the other half to come up with the worst possible solution: one that would make it extremely difficult to maintain and extend the system, that would prevent reuse, and so on. Let them work for a few hours and then put them back together. When comparing the results, it usually turns out that they gave almost the same results. The signatures on the components may vary, but the essence remains the same. Only now admit that they worked on different tasks, and discuss the consequences. Maybe it’s time to look for a new approach.

Despite the disadvantages of functional decomposition, it has its place — it is an excellent method for identifying requirements. It helps architects (or product managers) identify hidden or non-obvious areas of functionality. Even with fuzzy functional requirements, it is possible to start at the top level and decompose functionally down to a highly detailed level. You identify requirements and their relationships, build requirements into a tree system, and identify redundant aspects or mutually exclusive functionality. Nevertheless, the attempt to turn a functional decomposition into a design decision leads to fatal consequences. There should not be a direct correspondence between the requirements and the design solution.

Decomposition based on instability

The basis of the Design Method Method states:
Decompose based on instability

Decomposition based on instability identifies areas of potential change and encapsulates them in services or structural elements of the system. The desired behavior is then implemented in the form of interactions between the encapsulated regions of instability. The main reason for instability-based decomposition is simplicity: any changes are encapsulated and their impact on the system is isolated.

When you apply instability-based decomposition, you begin to consider the system as a series of storages.
Any changes contain the potential danger, like a hand grenade with a pulled pin. With instability-based decomposition, you open the door of the corresponding vault, throw a grenade, and close the door. Perhaps the entire contents of the vault will be completely destroyed, but there will be no fragments outside of it, destroying everything in its path. You have managed to contain the changes.

With functional decomposition, your building blocks represent areas of functionality, not areas of instability. As a result, when changes occur, by the very definition of decomposition, they will affect many (if not all) components of your architecture. Hence functional decomposition maximizes the effect of changes. Because most software systems are designed for functionality, changes are often painful and costly, and the effect of the change is likely to resonate throughout the system.

Designing a Trading System Using Volatility-Based Decomposition

• User instability. Brokers serve clients who work with their portfolios of securities. The client is also more likely to be interested in the current state of his funds. Although he can call the broker or write him a letter, in a more correct version, the client logs into the system in order to look at the current balance and data on current transactions. While the requirements are silent on client access (requirements are for professional brokers), this should be possible. It is likely that customers will not be able to perform transactions, but they should be able to view the status of their accounts. System administrators may also be present in the system. So there is instability per user type
• Instability of client applications. User instability often manifests itself in client application type and technology instability. For external clients checking their balance, a simple web page may suffice. However, a professional broker will prefer a multi-screen, full-featured desktop application with market trends, detailed account information, a quote feed, a news feed, spreadsheet projections, and the firm’s own information. Other users may want to view trends on different types of mobile devices
• Security instability. User instability refers to the instability of the way users are authenticated in the system. The number of internal brokers can be small, from a few dozen to a few hundred. However, a system can have millions of end-users. Internal brokers may rely on domain accounts for authentication, but for the millions of clients accessing information from the Internet, this is not an option. Perhaps a simple username and password will suffice for Internet users, or a system of complex unified federated security may be required. Similar instability exists with authorization methods. In short, security is unstable
• Notification instability. The requirements state that the system must send an email after each request. But what if the message is rejected? Should the system switch to paper letter fallback? Or maybe send a text message or fax instead of email? The request to send an email is a decision disguised as a request. The real requirement is user notifications, but the notification transport environment is not stable. There is also inconsistency in who receives a message: a single user or multiple users receiving the same notification over any transport channel. The end-user may prefer a documented statement on paper. There is also inconsistency over who posts the notification
• Storage instability. The requirements stipulate the use of a local database. However, over time, more and more systems are migrating to cloud platforms. There is nothing in stock trading that does not allow you to enjoy the benefits of cloud computing. The requirement to use a local database is really just another decision disguised as a requirement. A more correct requirement would be persistent data storage, which implies instability in storage options. However, the majority of users are people who limit themselves to executing read-only queries. It follows that the system will greatly benefit from the use of an in-memory cache. Moreover, some cloud technologies use an in-memory distributed hash table that has the same flexibility as the traditional file-based persistent storage method. The persistence requirement rules out the last two options because persistence remains a solution disguised as a requirement. The real requirement is only that the system must not lose data, or that the system must store the data in some way. The specific implementation of these requirements is a matter of implementation with a significant degree of volatility, from a local database to a remote in-memory cache stored in the cloud.
• Instability of the connection mode and synchronism. The current requirements specify a strictly synchronous way to fill out a web form and submit it. It follows that brokers will only be able to execute one request at any given time. But the more operations brokers perform, the more money they earn. If requests are independent of each other, then why not execute them asynchronously? If the requests are delayed in time (operations scheduled for the future), why not create a queue of calls to the system to reduce the load? When using asynchronous calls (including call queues), requests can be executed in any order. Connection mode and synchronicity are unstable
• Instability of session duration and devices. Some users complete a trade-in in one short session. However, brokers get the maximum profit when performing complex operations with the distribution and hedging of risks, with different types of stocks and sectors, in domestic or foreign markets, etc. Such transactions can take a long time, from several hours to several days. Such long-term interactions are likely to span multiple system sessions, possibly across multiple physical devices. There is instability in the duration of interactions, which in turn initiates instability of the devices and the connections involved
• Trading position instability. As mentioned earlier, over time, users may want to trade not only stocks, but also commodities, bonds, currencies, and even futures contracts. Trading positions themselves are unstable
• Process instability. If the trading positions are unstable, then the actions during the execution of the main phases of the operation will also be unstable. Buying and selling shares, scheduling orders, and so on. very different from selling commodities, bonds, and currencies. Thus, the sales process is unstable. Similarly, the process of analysis of operations is unstable.
• Instability of the local context and legislation. Perhaps, over time, the system will be deployed in other regions. Local context instability greatly affects trading rules, user interface localization, list of trading positions, taxation, and regulatory compliance. Consequently, the local context and the norms operating in it are unstable.
• Instability of the market data channel. The source of market data may change over time. Different channels use different formats, costs, refresh rates, communication protocols, and so on. They can give out slightly different prices for the same type of stock at one point in time. Channels can be external (eg Bloomberg or Reuters) or internal (eg simulated market data for testing, diagnosing, or analyzing trading algorithms. Data channels are not stable.

Key Observation

The above list does not by any means contain everything that can change in the exchange trading system. Its purpose is to point out those aspects that may change and present a general approach to finding unstable aspects. Some areas of instability may be outside the scope of the project. They may be ruled out by subject matter experts as being too unlikely. or they may be too strongly related to the nature of the business (for example, moving from equities to currencies or foreign markets). However, my experience shows that it is very important for a project to highlight areas of instability as early as possible and display them in the decomposition. Highlighting a project in architecture costs almost nothing. Later, you must decide whether or not to spend effort on its design and construction. However, now you at least know how to deal with this possibility.

System decomposition

Once areas of instability have been identified, they must be encapsulated in architecture components. One of the options is shown below.

The transition from the list of areas of instability to the components of the architecture is almost never unambiguous. sometimes one component can encapsulate more than one area. Some areas of instability may not correspond to components, but to working concepts such as queues or event publishing. In other cases, instability may be encapsulated in a third-party service.

When designing, always start with simple and easy solutions. Such decisions set limits in the system and simplify subsequent decisions. In the example above, some correspondences are easily established. Instability in data storage is encapsulated behind data access components that do not reveal information about where the storage is located and what technology is used to access it

I hope you enjoyed this article!
Thank you for reading, please follow me to get more interesting articles!