1. Identify architectural characteristics

When a decision is made to use software to solve a particular problem, a list of requirements for that system is gathered. A common software solution will package. Including the following characteristics, how do you extract the architectural characteristics required by a software from a pile of requirements?

In general, an architectural feature must meet three criteria to be recognized as a feature:

  • Identify a consideration for non-domain design;

  • Some structural items that affect the design:

  • Is critical to the success of your application.

  • Identify a consideration for non-domain design

When designing an application, requirements specify what the application should do, and architectural characteristics specify successful operations and design criteria for how the requirements are implemented and why certain decisions are made. For example, a common and important architectural characteristic that specifies a certain level of performance for an application and how many simultaneous users it needs to support is not usually present in requirements documents.

  • Certain structural items that affect the design

Consider whether you need in the framework of special structure design in order to guarantee success, to pay the scene, for example, we can through the third-party payment platform can also self-built payment ability, is likely to be that these two kinds of structure design of architecture have great influence, after all, money is directly related to the payment is with the user, the security is very important. Third party payment service: if the integration point handles payment details, the architecture does not need special precautions and only needs to follow the security specifications of service docking, no special structure is required; In-app payment services: If the application being designed must handle payments, specific modules, components, or services can be designed for the purpose of structurally isolating key security issues, so that both architecture and design are likely to have an impact.

  • Critical to the success of the application

It is particularly important to screen out the architectural features that the application must have. The more architectural features supported, the higher the complexity of design and implementation, so it is necessary to accurately evaluate the minimum key architectural features to implement. For example, a 2B heavy internal application with a small volume of requests does not require special architectural design and processing for architectural characteristics such as high concurrency.

1.1 Extracting architectural characteristics from domain problems

Common domain problems and corresponding architectural characteristics:

Field problem

Architectural features

cooperation

Interoperability, scalability, adaptability, extensibility

Release time

Agility, testability, deployability

The user experience

Performance, testability, fault tolerance, deployability, agility, security

Competitive advantage

Agility, testability, deployability, scalability, availability, fault tolerance

The cost of

Simplicity, feasibility

1.2 Extracting architectural characteristics from requirements

Some architectural characteristics come from explicit statements in requirements documents, such as the expected number and size of users often come up in domain issues, and some need to make judgments based on actual past experience, such as when building a course enrollment system

Architecture KATA approach:

  • The system tries to solve the overall domain problem

  • Users: The expected number or type of users of the system

  • Requirements: Whether the domain-level requirements are consistent with those provided by users

  • Additional context: There is a lot of implicit problem domain knowledge to consider that is not explicitly expressed in the requirements

2. Measure architectural characteristics

Exists in the whole software system architecture characteristics, from low-level code features such as modular to complex operation problems (such as scalability and flexibility), and there are a lot of ambiguity in different organizations/departments, so I need across the organization to agree on the definition of architecture characteristics, team around the architecture to create a common language, Make architectural characteristics measurable.

2.1 Operational measures

Many architectural features has obvious direct measurement, such as performance or scalability, mainly analyzes the user scale and the behavior, such as do a school attendance application at the time, in an eight – nine o ‘clock when there will be a large number of student credit card attendance, there will be a request flood peak, corresponding architecture characteristics based on the special scene, ready to cut some of the design.

2.2 Structural Measures

The measurable measure of code is complexity, generally defined by a circular complexity measure. Cyclic complexity is a code-level metric designed to provide a measure of code complexity at the function, method, class, or usage level. Computed by applying graph theory to code (especially decision points) that lead to different execution paths, such as CC=1 if a function has no decision statement (such as an if statement). If the function has a single condition, then CC=2, because there are two possible execution paths. The formula for calculating the CC of a single function or method is CC= e-n + 2, where N represents nodes (lines of code) and E represents edges (possible decisions). As shown below,

Public void test(int a, int b) {if (a < 100) { } else if (a + b > 500) {return 1; } else { return -1; }}Copy the code

CC provides metrics that allow us to ask questions during development: Is functionality complicated by problem domains or poor coding? Is the separation of the code bad? Can large methods be broken down into smaller logical chunks so that the work (and complexity) can be allocated to reasonable methods? The CC value below 10 is generally acceptable. If the CC value falls below 5, it is considered as a code with reasonable structure and good cohesion.

2.3 Process Measurement

Some architectural characteristics intersect with the software development process, such as agility, which can be divided into testability and deployability. This puts forward higher requirements for architecture design, better modularity and isolation.

  • Testability: On all platforms, code coverage tools can be used to assess the test integrity of code. As with all software inspections

  • Deployability: percentage of successful versus failed deployments, how long deployment takes, problematic bugs caused by deployment, and many metrics.

3. Governance architecture characteristics

A good architectural design is an evolving process that involves governance, which includes any aspect that influences the development process, such as adjusting the domain/module partition, technology layering, introducing new technology components, and so on.

Modularity is an implicit architectural feature that most architects are concerned about, because poorly maintained modules can compromise the structure of the code base. Having a network of components that refer to each other breaks modularity because developers can’t reuse individual components without using other components together. Of course, if other components are coupled to other components, the architecture becomes increasingly prone to the antipattern of big balls of mud.

For Java, you can use the JDepend utility class for loop dependency checks or the Maven dependency utility for IDEA

public class cycleTest { private JDepend jdepend; @BeforeEach void init() { jdepend = new JDepend(); jdepend.addDirectory("/path/xxxx/classes"); } @Test public void testAllPackages() { Collection packags = jdepend.analyze(); }}Copy the code

ArchUnit(a Java testing framework) provides a variety of predefined rules that allow you to write specific tests to solve modularity problems.

layerArchitecture() .layer("Controller").definedBy(".. controller.." ) .layer("Service").definedBy(".. service.." ) .layer("Dao").definedBy(".. Dao.." ) .whenLayer("Controller").mayNotBeAccessedByAnyLayer() .whenLayer("Service").mayOnlyBeAccessedByLayers("Controller") .whenLayer("Dao").mayOnlyBeAccessedByLayers("Service")Copy the code