📜 ⬆️ ⬇️

Application Architecture - Hot Spots

As part of our project , we brought together information on common approaches to the development of application architecture.

Common approaches are a collection of hot spots. However, these are not just hot spots. These hot spots are key questions, concerns, and recommendations. Together, they help develop more technically efficient architectures. This list is part of a more general App Arch Meta Frame structure. Think of it as an important branch of a large tree.

Categories

The following categories are hot spots in the application architecture:

Hotspots correspond to different end-to-end functionalities used in creating applications and, accordingly, to different sets of patterns and practices. For example, the Enterprise Library typically includes blocks responsible for caching, exception management, logging, validation, etc. The categories also correspond to various anti-patterns, the worst of which is the anti-pattern “do over”. :)

Key issues

This table lists the key questions for each hot spot:
')
Category
Key issues
Authentication and Authorization
  • How to store the identification data of registered users?
  • How to authenticate requests?
  • How to authorize requests?
  • How to transfer user credentials between application layers?

Caching and state
  • How to choose an effective caching strategy?
  • How to increase performance using caching?
  • How to improve security with caching?
  • How to improve stability with caching?
  • How to keep the cache up to date?
  • How to determine when and how to use specialized cache?
  • How to determine what data to cache?
  • How to determine where to cache data?
  • How to determine the rules for deleting data from the cache due to obsolescence or overflow?
  • How to load cache data?
  • How to monitor the cache?
  • How to synchronize multiple caches with each other?
  • How to determine which caching method provides the greatest performance and scalability for a particular scenario and configuration.
  • How to determine which caching technology meets the application’s requirements for security, ease of management, and
    monitoring.

Interaction
  • How to transfer information between application layers?
  • How to make asynchronous operations?
  • How to transfer secret data?

Composition
  • How to design the structure of the application?
  • How to design weak connectivity between modules?
  • How to work with dependencies in loosely coupled mode?

Parallel Computing and Transactions
(approx. translator): Here the author has duplicated the previous category. If the error is corrected in the original, then I will correct the translation.
Configuration management
  • How to determine which information is configurable?
  • How to determine where and how to save configuration information?
  • How to work with secret information?
  • How to work with configuration information in a cluster?

Connectedness and grip
  • How to divide the functionalities?
  • How to structure the application?
  • How to choose suitable splitting into layers?
  • How to set the boundaries between parts of the system?

Data access
  • How to manage database connections?
  • How to manage exceptions?
  • How to improve performance?
  • How to improve manageability?
  • How to work with binary data (BLOBs)?
  • How to use paging for recordings?
  • How to manage transactions?

Work with exceptions
  • How to handle exceptions?
  • How to save information about exceptions?

Logging and monitoring
  • How to determine what information to write to the log?
  • How to make a log entry customizable?

User interaction
  • How to improve the performance of tasks?
  • How to improve the responsiveness of the interface?
  • How to improve the capabilities of the application for the user?
  • How to improve the appearance of the application?

Data checking
  • How to determine where and when to validate the data?
  • How to check the length, range, format and data type?
  • How to restrict the input data and report incorrect values?
  • How to secure (sanitize) the output?

Workflow
  • How to solve parallel computing problems in the workflow?
  • How to handle errors in the workflow?
  • How to coordinate processes in the workflow?


Key issues

This table summarizes the key issues for each hot spot:
Category
Key issue
Authentication and Authorization
  • Storage of identification data in clear form in files.
  • The transmission of identification data in the clear over the network.
  • Accounts with excessive privileges.
  • Long-lived sessions.
  • Mixing personalization and authentication.
  • Using a single access controller (gatekeeper).
  • No restrictions on access to system resources for the application.
  • No restrictions on access to the database except for certain stored procedures (stored procedures).
  • Inadequate separation of access rights.

Caching and state
  • Cache slips.
  • No expiration (expiration) of data in the cache.
  • Bad cache architecture.
  • Lack of synchronization cache, necessary for good system scaling.

Interaction
  • Increased network traffic and delays due to "heavy" messages between the layers.
  • Failed transport protocols and message formats.
  • Too much data in limited bandwidth networks.

Composition
  • Closely related modules
  • Duplicate code

Parallel Computing and Transactions
  • Blocking calls.
  • Non-granular data locking (nongranular locks).
  • Incorrect work with threads.
  • Data blocking lasts too long.
  • Incorrect database isolation levels.

Configuration management
  • Insecure administration interfaces.
  • Insecure configuration repositories.
  • Storage of configuration data in open form.
  • Too many administrators in the system.
  • Too many privileges for service accounts and processes.

Connectedness and grip
  • Limited scalability due to tight attachment to server and resources.
  • A mix of presentation and business logic levels that limits scaling.
  • Problems with further support due to excessive connectivity.

Data access
  • Use a separate username / password for each user when it is not necessary.
  • "Heavy" queries to the database.
  • Dispersed by class business logic.

Work with exceptions
  • Leaving the system / application in an unstable state.
  • Opening of secret information to end users.
  • The use of exceptions for the operation of logic.
  • Logging insufficient information about the exception.

Logging and monitoring
  • Lack of logs and monitoring.
  • Logging and monitoring details are too high.
  • Lack of settings for logs and monitoring during execution (run-time).
  • Opt-out of logs for critical business operations.

User interaction
  • Inefficient support for user tasks.
  • Bad response time.
  • Ignoring users with disabilities.

Data checking
  • Filtering erroneous data only at the application level.
  • Insecure HTML output.
  • Insecure data insertion in SQL.
  • Data verification only on the side of the user.
  • Use file names, URLs, or user names to make security decisions.

Workflow
  • Strong connectedness.
  • Inflexible processes.
  • Problems with priorities and deadlocks (race and deadlock issues).


Key recommendations

This table provides key recommendations for each hotspot:
CategoryKey recommendations
Authentication and Authorization
  • Think about registration requirements.
  • Separate all open and closed areas.
  • Use end user account blocking policies (for example, if multiple password errors occur).
  • Maintain a custom password expiration.
  • Provide the ability to disable accounts by the administrator.
  • Do not store passwords.
  • Require strong passwords.
  • Do not send passwords in clear text over the network.
  • Protect cookies with credentials.
  • Use multiple access controllers (gatekeepers).
  • Restrict user access to system resources.
  • Consider the granularity of access rights.

Caching and state
  • Try not to cache data created for only one user.
  • Do not cache data that should be accurately provided to the user and updated in real time.
  • Cache data that does not change very often or is completely static.
  • Do not cache very "heavy" resources.
  • Cache data after transformations, given the relevance of the information on which they are based.
  • Compare the applicability of designs with stateful and stateless storage.
  • Consider storage options.
  • Minimize the size of the data in the session.
  • Release session resources as quickly as possible.
  • Try not to request session data from business logic.

Interaction
  • Select the appropriate mechanism for remote interaction.
  • Make compact and convenient external interfaces.
  • Think about how to transfer data between layers.
  • Minimize the amount of data transmitted over the network.
  • Use batch jobs to reduce the number of calls over the network.
  • Avoid transactions running between the boundaries of parts of the system.
  • Consider the possibility of asynchronous interaction.
  • Examine the possibility of using message queues.
  • Assess the applicability of the “shot and forget” approach.
  • Shorten call processing chains with caching. This will improve scalability.
  • Move asynchrony closer to the user, service interfaces, and service agents to insulate the service from external dependencies.
  • If you are forced to make some functionality synchronous, then consider whether it is possible to make its part asynchronous inside.

Composition
  • Avoid using dynamic layouts that are difficult to load and maintain.
  • Be careful with dependencies between components. Use abstraction patterns as soon as possible to reduce potential problems with system support in the future.
  • Try to use templates with the ability to insert data (placeholders). For example, use the Template View pattern to create dynamic web pages for reuse and consistency.
  • Consider creating views from reusable modules. For example, use the Composite View pattern to create a set of elementary parts working as ready-made modules.
  • Use well-known patterns to create composite interfaces containing individual user control modules.
  • Modules should not directly refer to each other or to the application that loads them.
  • To interact with other modules and the application itself, you must use services.
  • Modules should not be responsible for managing their dependencies.
  • It is desirable to support the addition and removal of modules as plugins.

Parallel Computing and Transactions
  • Treat the thread as a shared resource.
  • Create pools of shared resources or resources that are too few.
  • Request a resource as soon as possible, release as soon as possible.
  • Learn the effectiveness of the creation and destruction of objects.
  • Consider bandwidth resource management.
  • Reduce possible delays by minimizing resource lockout time.
  • Keep a balance between high-level (coarse) and low-level (fine) locks.
  • Select the appropriate insulation level.
  • Avoid long-running atomic transactions.

Configuration management
  • Protect system administration interfaces.
  • Protect your configuration repository.
  • Separate administrative authority.
  • Use the lowest possible privileges for process accounts and services.

Connectedness and grip
  • Break the application into logical layers (layers / tiers).
  • Choose the right location for parts of the application, depending on your requirements for reliability, performance, and scalability.
  • From the very beginning, design a system with weak connectivity.
  • Design a system with a strong grip.
  • Use early binding where possible.
  • Assess resource affinity.

Data access
  • If your application uses a single database, then use a specialized provider instead of a universal provider for greater speed.
  • If you support several types of databases, then you need a special level of abstraction that can be easily customized for a specific environment.
  • Try to manage bandwidth resources.
  • Examine the transfer to the database of user IDs.
  • Separate read-only and transactional requests.
  • Do not return data that will not be used.

Work with exceptions
  • Do not show users the data that reveal the insides of the system.
  • Do not use exceptions to control the flow of application execution.
  • Use error codes instead of exceptions where possible.
  • Do not catch exceptions that you cannot handle.
  • Note that rethrowing is an expensive operation.
  • Keep as much diagnostic information as possible in your exception handlers.

Logging and monitoring
  • Constantly monitor.
  • Make the logs customizable.

User interaction
  • Check performance for different scenarios.
  • Work on improving the response time of the system.
  • Start off with an effective user interface design.

Data checking
  • Check data for length, range, format and type.
  • Limit the input and report errors.
  • Secure your input.
  • Do not rely on client side validation.

Workflow
  • Identify workflow management requirements. If they are to be managed by a business user, then provide them with a clear interface.
  • Determine how exceptions will be handled in the workflow.
  • When you have with a workflow related to people, do not forget about the uncertainty of human nature. You can not rely on the fact that some task will be completed at some time and will be fully implemented.
  • Use service interfaces to work with external workflow providers.
  • Use visual editors and metadata to develop workflows instead of code, if possible.


From the translator: I love a concise analytical approach, therefore I translate. :) And in general, I recommend the author's blog. There are many brain-friendly lists and tables. Reasonable amendments to the translation of terms are welcome. Discussion of controversial points - too.

Source: https://habr.com/ru/post/40660/


All Articles