This is the 18th article on the System Design and Software Architecture series. In this article, we are discussing the Boundary Anatomy in software engineering.

Previous articles

Contents hide
1 Previous articles
2 What is System Boundary Anatomy?
3 Dangerous monolith
4 Deployment Components
5 Threads
6 Local Processes
7 Services
8 Conclusion

What is System Boundary Anatomy?

What is System Boundary Anatomy_
What is System Boundary Anatomy_

The architecture of a system is defined by the set of software components and the boundaries that separate them. Those limitations come in many forms. In this chapter, we will look at some of the most common ones. Boundary crossing during run time, crossing a boundary is a function of passing data by calling a function on one side of the boundary and a function on the other. The strategy for creating a suitable boundary cross-section is to manage the source code dependencies.

  • Why the source code?
  •  When one source code module changes, the other source code module may need to be modified or rearranged, and re-applied. Managing and building a firewall against this change is a limitation.

Dangerous monolith

Dangerous monolith
Dangerous monolith

The simplest and the most common of the architectural boundaries is not a rigid physical representation. It is a disciplinary separation of functions and data within a single processor and single address space. In a previous chapter, I referred to this as the source-level disconnection mode. From a deployment point of view, this is nothing more than a single executable file. This file can be statically linked to C or C ++ project, and it is a group of Java class files attached to an executable container file. The fact that the borders are not visible when using monoliths means that they are non-existent and meaningless. Although statistically linked to a single functional unit, the ability to independently develop and marshmallow the various components for final assembly is invaluable. This is one of the reasons why object-oriented development has become such an important role model in recent decades. Without OO or similar polymers, architects must fall into the dangerous habit of using indicators for functions to achieve optimal decomposition. Many architects use pointers extensively for hazardous tasks, forcing them to abandon any type of component partitioning. The most straightforward possible border crossing is a functional call from a low-level client to a high-level service. Both run-time dependency and compiler-time dependence are in the same direction, towards higher level compression.

Deployment Components

Deployment Components
Deployment Components

An architectural boundary’s most straightforward physical representation is a dynamically linked library, such as .NET DLL, a Java container file, a Ruby gem, or a Unix shared library. Deployment is not related to compilation. Instead, local processes 179 components are provided in a binary or similar deployable form. This is the deployment level deployment method. The deployment function is simply to assemble these deployable units in a convenient way, such as a WAR file or directory. With that one exception, the deployment level components are similar to monoliths. All functions are on the same processor and address space. The strategies for managing components and their dependencies are similar. Also as in monoliths, communication across deployment component boundaries is only active calls and therefore very inexpensive. Dynamic connection or runtime loading that has ability to a one-time hit, but communicating through these limits is also still tricky.

Threads

Threads are used for both of monoliths and deployment components. Threads are not architectural boundaries or deployment units, but those are a way of organizing the implementation schedule and sequence. They are contained entirely within one component, or they can spread across many components.

Local Processes

Local Processes
Local Processes

A stronger physical architectural boundary is the local process. A local process is usually generated from the command line or similar system call.

  • Local processes run on the same processor or on the same processor on multiple processors, but it is in different addresses. Memory protection usually prevents such processes from sharing memory, and shared memory partitions are often used.
  • Static multimeter is not an option in this case. Chapter 18 Boundary Anatomy 180 Often local processes communicate with each other through other operating system communication facilities, such as sockets or mailboxes or message queues.
  • Every local process is a statically connected monolith, or it can consist of dynamically connected diffusion components. In the former case, several monolithic processes may have been composed and linked together.
  • Second, they share dynamically connected diffusion components. Think of a local process as a kind of uber-component: this process consists of low-level components that manage their dependencies through a dynamic multimeter. The separation strategy between local processes is similar for monolithic and binary components. The source code dependencies point in the same direction across the boundary and always point to the higher level component.
  • For local processes, this means that the source code of high-level processes should not contain physical addresses or registry view keys, if they are lower-level processes.
  • The architectural goal is to plug lower-level processes into higher-level processes. Operating system calls, data marshal and decoding, and interaction context switches for communication across local process boundaries. Chats should need to always carefully restricted.

Services

The strongest limit is service. A service is a process that usually begins with a command line or similar system call. Services do not depend on their physical location. Two communication services can operate on the same physical processor or multifunction. Services assume that all communications take place over the network. Conclusion 181 Communication across service limits is very slow compared to active calls. Reversal times can range from ten milliseconds to seconds. Always be careful not to talk wherever possible. This level of communication has to deal with high level of delays. Otherwise, the same rules apply to services that apply to local processes. Lower level services must need to “plugged in” to higher level services. The source code for higher level services should not contain any specific level physical knowledge (e.g., URI) of any lower level service.

Conclusion

Thanks for reading the article Boundary Anatomy as an essential component in System design and architecture.

My articles on medium