Good architecture is what makes a system scalable, maintainable, and understandable. It’s not just for big enterprises or legacy systems—it’s essential from day one if you want to build software that lasts.
There are a ton of definitions out there. The industry did not yet agree on a single definition of software architecture.
There are also different views on architecture, for example the deployment view or the runtime view. In TangleGuard we focus on components and the static relationships within the the source code of an application.
Here, software architecture consists of the following things:
Components
In some way or the other you want to group and separate logic of your code. Therefore you need to introduce boundaries which specify those groups. Programming languages provide the following mechanisms to group logic:
Tanlge Guard let’s you also have an additional kind of component: layers
Components can be nested, so one component can contain other components. So usually a package contains multiple modules, and a module contains multiple functions.
Dependencies
Whatever you choose as container to group your logic, it needs to interact with other component. Which component is being used by another component is specified via a dependency.
Rules
To have a well-defined architecture, you need to define rules which specify which component is allowed to depend on which other component. This is how you’ll be able to keep your architecture clean and maintainable. TangleGuard currently supports a whitelist which specifies which layers another layer can depend on.
A layer is a special component which imply dependency rules. They do not exists technically, it’s more conceptual. The following types of layers exist:
Those are groups of components which group technical concerns. An example of a horizontal layer would be to have an API layer, which contains a REST API packages and a GraphQL API package. All logic domains related to API are grouped together in this layer, no matter what business domain they belong to.
They are also called horizontal layers - they cut across the business domains.
They are visualized as wide, shallow blocks in the architecture diagram.
TODO: Visualization
Domain layers are groups of components which group business concerns.
An example of a domain layer would be to have a User layer which contains all logic related to the user domain, like user management, user profile, etc.
Therefore they contain all technical concern related to this domain, like the API, the database entities, etc.
They are also called vertical layers - they cut through the horizontal layers.
TODO: Visualization
Architecture can feed abstract although it is very concrete and practical once you get the hang of it. To make it more tangible, visualization help help massively. It makes talk about the design easy and is a way to communicate a architecture which someone has in mind.
Below You see two component A and B.
Component A depends on component B.
Components are visualized as rectangle whereas the dependency is visualized by the arrow as follows:
Example of packages and modules:
Example of layers and packages:
Below you see two horizontal layers A and B and one vertical layer C.
Below the allowed dependencies are marked in green. The red lines are examples of dependencies which are hence not allowed.
