Finding the best architecture suited for your culture

I always believe that an organisational culture reflects production culture. I have been working in startup companies throughout my professional career -including my company- since i graduated from the university. And every time, i had a chance to create a team and development culture from the scratch. People who had been experienced in working at a startup company can understand me well. Anyway, you would like to create a team with full of rock stars... Limited funding... you think you had at most two changes to release your product and of course you barely know how to sell it...

There are lots of practices to start a new product. It's absolutely reasonable that you should make a prototype first and proof your idea, then get funding, increase your resources and design + implement your glowing and bubbling product again. Because millions of millions of users are holding their breathes and waiting for your product (am i right ?). So now, you should decide or you have to hire some one to decide the next step.

In the next step, you probably would like to use your wealth to get wealthier than now. Hence, reaching your users at high scale is not as easy as you did before. Spending some money for re-organisation... paying more salaries to hire qualified engineers etc. Right here, right now, if your are a technology oriented company and spending your money for your technology infrastructure and have complex domains. Someone would say that "if we want to redesign our software infrastructure, maintainability, flexibility and scalability should be our key concerns to think about...". And the reasoning should come in; "if we need to construct a well communication flow and integration between all parts of our complex domains, we should also come up with a solution to this with the new architecture."

In this post i would like to help those who are in the next step by trying to explain next generation architecture approaches developed by software gurus.

According to Conway's law, "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." As it is clearly stated that there is a strong relationship between organizational structures and software, even codebase structures and conventions.

The law is based on the reasoning that in order for a software module to function, multiple authors must communicate frequently with each other. Therefore, the software interface structure of a system will reflect the social boundaries of the organization(s) that produced it, across which communication is more difficult. Conway's law was intended as a valid sociological observation, although sometimes it's taken in a humorous context. (Source : Wikipedia)

Building up a team according to their functionalities or domain knowledge is a strategical decision. There will be another post to discuss functional organisation of a software development team.
Database-centric architecture, Source : pluralsight
The visualisation above shows the relationship between a software architecture layers and functional teams in a traditional organisation.

I have to admit this post includes quotations from Clean Architecture course in Pluralsight which i reviewed in my another post. here.

Traditional Database-centric Architecture

In the database-centric architectures, database is in the center of the organisation. In this approach, UI, business logic and data access depend on the database. It is the essential part of the system naturally. Everything goes around the database. It's worth denoting that i'm not aiming at campaigning to discredit this approach, but there are some facts we cannot ignore.

Database-centric architecture, Source : pluralsight

Disadvantages of Database-centric Approach
  • It was just designed to serve single type of presentation layered applications. I mean before smart phones comes into play.
  • It is not flexible and agile. You cannot move the essential parts because the parts which you want to change are stick to the layer up or down.
  • All dependencies are towards the database.

Domain-centric Architectures

In domain-centric architectures the domain and use cases are essential, presentation and databases are just a detail.

Domain-centric architecture, Source : pluralsight

All dependencies point towards the domain. There are three well known domain-centric architectures. One of them is "hexagonal architecture" from Alistair Cockburn, It is layered architecture model that application is at the center of the system. It is a plugin architecture which includes ports and adapters.

Next with the onion architecture, Jeffrey Palermo. This is also a layered architecture with the domain at the center surrounded by the application layer. The outer layers consist of a thin UI as a presentation layer and an infrastructure layer which includes persistence layer. In addition all dependencies point towards the center of the architecture. There is no inner layer knows about any outer layer

In this architecture, we can test application without UI and database dependencies.

Database-centric architecture, Source : pluralsight

Finally author mentions about Clean Architecture from Uncle Bob here.

In this architecture, entities are at the center surrounded by the application that is the use cases. The outer layer consists of ports and adapters adapting the application core to the external dependencies via controllers and gateways and presenters. The little illustration at the bottom right of the image below is Ivan Jacobson's BCE architecture pattern to explain how the presentation layer and application layer should be wired up.

These three architectures are focusing to come up with the same solution. The fundamental issues in traditional architectures like tight coupling, separation of concerns are all addressed by them pragmatically. As you've already known that traditional MVC like architecture is one of the most used and accepted approach in industrial applications. But things are changing and visionaries are aware that designing softwares that UI - business logic and business logic - persistence layer are tightly coupled is not a good way of designing software, because of maintainability and flexibility issues.

Technology is always changing because of the real world needs so, successful change management becomes increasingly important subject for businesses. For instance, What happens in the case of replacing your data access system from relational database to any NoSQL data storing system or adding another NoSQL ? What if you want to change your caching storage system from one to another ? Long story short, this shouldn't be a pain in the ass on your every attempt for a change.