home | syllabus | groups | moodle | video | review | © 2022
- Asks "what is the problem?"
- what happens in the current system?
- what is the requirement in the new system?
- Leads to a detailed understanding of Requirement and Domain Properties
- Focuses on the way human activities are conducted
- Asks "how to build a solution?"
- how will the new system work?
- how can we solve the problem identified by the analysis?
- Leads to a solution to the problem
- Focuses on building technical solutions
A software architecture defines multiple things:
- The components of a software system
- How the components use each other's functionality and data
- How control is managed between the components
- Servers provide some kind of service.
- Applications are run locally by the end user
- (e.g: Running on local machines, and mobile devices)
- Data storage and management is treated as a server.
- Consistency checking is located on the server
- Advantages:
- Breaks the system into manageable components
- Makes control and data persistence clearer
But here are we talking about logical or physical architecture? Well both but with a larger focus on logical architecture.
-
When designing architectures we usually think about basic building blocks:
- Modules: which are self contained functionalities
- Connectors: Interfaces that connect different modules
-
A good architecture will generally minimize coupling between modules and maximize the cohesion of each module
-
This makes it easier for future changes and maintenance to code, as well as making the modules easier to understand.
- Used in UNIX shell commands
- Compilers:
- Lexical analysis -> parsing -> semantic analysis -> code generation
- Signal Processing
- Filters do not need to know anything about what they are connected to
- Filters can be implemented in parallel
- Behavior of the system is the composition of the individual behaviors of the filters
- Used in conjunction with DDD and Microsservices architecture for most real world applications, also very useful for debugging systems, for database management systems, and GUIs
- Anouncers of events don't need to know who will handle the event
- Supports re-use, and enhancement of the system
- Components have no control over order of computations
- Used in most real world applications, also used to develop operating systems and communication protocols
- Support increasign levels of abstraction during design
- Support enhancement and re-use
- Can define standard layer interfaces (think pipe-and-filter)
- May be hard to identify clean layers
- Without further architectural transformations tends towards a monolithic architecture.
- A layer can use services from any layer below it
- More compact code, as the services of lower layers can be accessed directly
- Breaks the encapsulation of layers, so it increases dependencies between layers
- Each layer only uses services of the layer immediately below
- Minimizes dependencies between layers and reduces the impact of a change
CQRS stands for Command Query Responsibility Segregation the concept was first introduced as an idea to separate into different modules actions that alter persisted data, and simple queries that retrieve persisted data.
When developing systems on the modern distributed era:
- individual modules are deployed in separate machines
- connectors are deployed as event queues (Think event based architecture)
As such, the persisted data may often come from different asynchronous sources. And when retrieving data (for the majority of cases), it is acceptable to have non atomic information.
With that in mind reading data becomes a very different process than the rest from CRUD (Create, Update, Delete).
- Reads and Writes are considered wildly different actions in CQRS allowing for validations to work in completely different manners from a traditional DDD system.
- Allows for an easier time when moving the application from local hosting to cloud hosting.
- Many applications are not complex enough to justify the extra work required with CQRS
- Needs to be deployed together with an event based architecture
With the advent of cloud technologies and current the high availability of low cost cloud services the architectural landscape went through changes.
Most of the applications were originally of a monolithic nature, which means that a server (physical machine) would contain all layers, all API's, all database access, all authorization services contained within the same process.
The problem with this approach, is that in real life, not all services and features of a system require the same computational resources, and for many services the features that require computational resources at high demand vary over time.
So there is a very large cost with providing a cloud environment capable of serving sufficient users in a scalable and financially conscious manner.
As such the concept of microservices appeared. To transform any architecture cited above in microsservices we have to break down and achieve a very high level of low coupling and high cohesion, so that you can break down separate modules of the application and deploy them separetely as microsservices.
One very successfull architecture that easily breaks down into microservices is CQRS with Domain Driven Design when coupled with an event based approach to the architecture.
- If a feature is in high demand, it's easy to instantiate more computing power focused for it. Alternatively services in low demand can require less computing power. (Better Scalability)
- Better overall control of the whole application, easier time identifying bottlenecks and points to be optimized in the system
- Can increase development time.
- Complex behaviours require complex solutions due to the complete independency of modules locally
- Deployment and DevOps becomes significantly more complex