Software Architecture — Principles, Practices & Styles

What is bad architecture and how to recognize it?

  1. Unnecessarily Complex — Ironically it is easy to write complex code, anyone can do it, but it is hard to write simple code.
  2. Rigid/Brittle — Since it is unnecessarily complex, it is not easy to understand and therefore making it non-maintainable, easy to break for even a small code change.
  3. Untestable — Such code will be tightly coupled, will typically not follow the single responsibility principle, will be difficult to test.
  4. Unmaintainable — Brittle code with less test coverage evolves to becomes a maintenance nightmare

What is good architecture and what properties do they exhibit?

  1. Simple — Easy to understand.
  2. Modularity/Layering/Clarity — This is important so that one layer is able to change independently of the others with minimum coupling between the layers
  3. Flexible/Extendable— Can be easily adapted to new evolving requirements
  4. Testable/Maintainable — Easy to test, add automated tests, and encourage the culture of TDD and therefore maintainable

Why bother about architecture, principles, practices?

What tools, methodologies, and techniques can we follow?

  1. Lean principles — Build the right thing. Build what is necessary.
  2. Agile methodology— Build the right way. Build software in a way that is agile, adaptable, fast to respond to changing market requirements
  3. Test-driven development practice & Automated Tests — Test drive implementation ensuring testable software design. This supports the Shift Left methodology, “Test early, Test often” resulting in maintainable code as it eliminates the fear of breaking existing functionality un-intentionally.

What architecture styles are followed?

  1. Domain Centric Architecture
  2. Application Centric Architecture
  3. Screaming Architecture
  4. Microservices architecture
  5. Event-Driven Architecture — EDA
  6. Command Query Responsibility Segregation — CQRS

Domain Centric Architecture

Original source:
Original Source:
  1. This allows for Domain-Driven Design (DDD) thinking. The focus is on a domain, users, and use-cases.
  2. Reduced coupling between domain (stable and changes less) and the implementation detail (which changes faster like presentation layer, database)
  1. The initial cost is higher as more time/thought/discussion has to be put into separate models needed for the domain versus application layer rather than all models just put together.
  2. Developers tend to avoid it, as it requires more thought. They stick to the old 3 layered Database Centric Architecture

Application Centric (Layered Architecture)

Original source:

Functional Organization of code (Screaming Architecture)

Original Source:
Original source:

Microservices Architecture
  1. The initial cost is higher
  2. DevOps automation is necessary as automated deployment is now a need.
  3. Extra time and cost is incurred to deal with such distributed computing in terms of latency, load balancing, logging, monitoring, dealing with eventual consistency, etc

Event-Driven Architecture (EDA)

CQRS pattern-Command Query Responsibility Segregation

  1. You can improve your read scalability without impacting the write. For example, by adding more secondary nodes in MongoDB to serve the read requirements, you selectively scale the read capability.
  2. The command has to send the updates to the database. You may choose to have a caching layer to provide for faster reads.
  3. Sometimes the object may belong to another microservice and querying another microservice every time may be costly, so you can use the caching layer for your query needs. Data is duplicated but as long as it is maintained, and is not changing very fast, you are able to reduce the latency to a good extent. This sometimes offers resilience too. Even if the other microservice is not available your microservice can continue to work normally. ex. Caching the product catalog in the Order-microservice.




Java Architect | MongoDB | Oracle DB| Application Performance Tuning | Design Thinking |

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

How to bring requirements, risks, tests and issue management together (Part 2 of 2)

‘Optional’ Abstraction — The solution to the “Billion-Dollar Mistake”

Sorted Data Structure in C#: An Introduction to SortedDictionary, SortedList, and SortedSet

[Mobile] iOS v2.7.0 update — Chroma-Key, ISO & WB in camera pro mode

Debugging Deadlock in PininfoService Ubuntu18 Upgrade: Part 1 of 2

on the left, an octopus all tangled up in its own tentacles. On the right, the octopus is untangled and happy. There is an arrow between the two pointing to the untangled octopus. The arrow is labeled “unlock”.

AMA with Coinvision: Real World Solutions and Core Applications of StrongNode Technology

Handling the Complexities of the AWS Bill (Yes… including RIs!)

How to Build a Chatbot from a Chatbot Template — A detailed guide — WotNot

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Sarada Sastri

Sarada Sastri

Java Architect | MongoDB | Oracle DB| Application Performance Tuning | Design Thinking |

More from Medium

Microservices all the way, or not?

Moving from a Monolithic to Microservices Architecture

Story of the mention component

mention component example

What may make an architect sad at EPAM?