Tag: Architecture

Architecture

Steps in Architecting Solution Delivery and Maintenance Lifecycle

smitbmxLeave a comment
  1. Define the customer requirements for the solution.
  2. Design a great solution to meet those requirements.
  3. Implement the designed solution.
  4. Test the solution implementation.
  5. Validate the solution with the customer.
  6. Deliver the solution in the working environment.
  7. Maintain the solution afterward.

Fundamental constraints

  1. The solution needs to meet user requirements.
  2. The solution needs to be delivered on time.
  3. The solution needs to adhere to the project budget.
  4. The solution needs to deliver good quality.
  5. The solution needs to guarantee safe and effective future evolution.
Architecture

Event Driven Architecture – Full Guide

smitbmxLeave a comment

Agenda:

  1. Microservices Architecture
  2. Command and Query
  3. Event
  4. Event-Driven Architecture (EDA)
  5. Producer
  6. Channel
  7. Consumer
  8. Advantages of Event-Driven Architecture
  9. Orchestration and Choreography
  10. Event Sourcing Pattern
  11. CQRS Pattern
  12. When to use Event Sourcing and CQRS
  13. Stateless EDA
  14. Stateful EDA
  15. Event Streaming
  16. Correlation Id
  17. Mixing EDA with Request/Response
  18. Events as Source of Truth
  19. The Saga Pattern

1. Microservices Architecture

  • Based on loosely coupled services.
  • Each service is in its own process.
  • Lightweight communication protocols.
  • Polyglot – no platform dependency between services.

Replaces 2 legacy architectures as Monolith and SOA (Service Oriented Architecture).

The most important part in the EDA is the microservices communication. Which is dictated performance, and scalability. So the Event Driven Architecture handles the communication part.

Typical Microservices Architecture
Continue reading “Event Driven Architecture – Full Guide” →
Software

Code Smells (Anti-Patterns)

smitbmxLeave a comment
  1. Comments – public methods should have comments. In the same time too many comments is bad and means that the code is unreadable without the comments. The code should be clean enough to avoid comments inside of the methods. Also, you should to avoid the comments which saying “if you update this, then update the next…”.
  2. Duplicated code – is when you have blocks of code that are similar but with slight differences. These blocks appear in multiply places of the system.
  3. Long method – self explained, you don’t want to have long methods. Having a long method can sometimes indicate that there is more occurring in that method than should be. Or it’s more complex than it needs to be.
  4. Large class – its referencing the “God classes”/”Black hole classes” which are getting bigger and bigger. They normally start as a regular size class. But as more responsibilities are needed, these classes seems like the appropriate place to put the responsibilities. But as it going to have more responsibilities, then it tend to attract more responsibilities, hence the class going to be larger and larger and keeps attract more and more responsibilities. To avoid this, you need to be explicit about the purpose of the class and keep the class cohesive, so it does one thing well.
Continue reading “Code Smells (Anti-Patterns)” →
Software

Observer Pattern

smitbmx1 Comment

Visualization example: let’s say you want to know about the new articles of this blog. You can make software which will check the updates every 1 minute or every 1 hour or even a day. But maybe you need to know immediately, then the observer pattern can help, where the blog will notify you every time a new post is added. You would subscribe to the blog. Every time when new post is published, the blog will notify each subscriber, including you. Hence you don’t need to pull for this information at some interval.

Subject – blog, will keep the list of Observers (subscribers to the blog).

We’ll have a Subject superclass, that defines three methods:

  • Allow a new observer to subscribe.
  • Allow a current observer to unsubscribe.
  • Notify all observers about a new blog post.
Continue reading “Observer Pattern” →
Software

Separation of Concerns

smitbmxLeave a comment

Separation of Concerns principle helps to create flexible, reusable and maintainable software systems. But it is an ongoing process throughout the design process.

Concern it is anything that matters in providing a solution to a problem. Some of the concerns in software may involve:

  • What information the implementation represents.
  • What it manipulates.
  • What gets presented at the end.

Example with SmartPhone, let’s say we have the next class:

Continue reading “Separation of Concerns” →
Software

Coupling and Cohesion

smitbmxLeave a comment

Coupling and cohesion are metrics to evaluate design complexity.

These metrics helps to achieve a more manageable system.

Coupling

Coupling focuses on complexity between a module and other modules. If your module is highly reliant on other modules, then this module is tightly coupled to others (puzzle). If your module finds it easy to connect to other modules, this module is loosely coupled to others (Lego).

Coupling.png
Coupling

When evaluating the coupling of a module, you need to consider degree, ease and flexibility.

Continue reading “Coupling and Cohesion” →
Software

UML Class Diagram of a car rental company

smitbmxLeave a comment
Car Rental Company UML class diagram.png

This example has the next 4 entities:

  1. Car Rental Company: company itself, which is the “whole“.
  2. Car: cars owned by the company.
  3. Rental: rental entity (like contract), which is the “whole” for Car and Renter entities.
  4. Renter: a person who rent car.

All of the connections are composition. The system has the next generalization connections:

  • Car Rental Company – Car: the company can have 0 or many cars; a car can have only 1 company.
  • Car Rental Company – Rental: the company can have 0 or many rentals; a renal can have only 1 company.
  • Car Rental Company – Renter: the company can have 0 or many renters; a renter assigned only o 1 company.
  • Rental – Car: 1 rental can be assigned to 1 car and vise versa.
  • Rental – Renter: each rental can have only 1 renter but a renter can have 0 or many rental.

Software

Software Quality Attributes

smitbmxLeave a comment

The attributes in the article are technical capabilities that should be used in order to fulfill the non-functional requirements, so the most important and common quality attributes are:

  1. Scalability.
  2. Manageability.
  3. Modularity.
  4. Extensibility.
  5. Testability.

In reality there are much more quality attributes: wikipedia.

Intro illities.png

Scalability

Adding computing resources without any interruption.

Non-Scalable System, which obviously require a lot of efforts to fix it:

  1. Look for non-scalable code.
  2. Rewrite non-scalable code.
  3. Reinforce VM.

Scalable System:

  1. Add VM.
  2. Notify the Load Balancer.

There are 2 types of scalability: scale up (vertical) and scale out (horizontal).

ScaleUpScaleDown.png

The preferable option is Scale Out which has 2 main benefits:

Continue reading “Software Quality Attributes” →