What is the Level of your Tech Start-up? Part 1/3. Software Technical Architecture
This article is a part of a Series “What is the Level of your Tech Start-up?”. It consists of three Articles, aimed to define and describe two main Viewpoints when creating new Tech Company: Technical and Business, and how they combine together.
Intro
Although the name suggests applying this Approach to Start-ups, it can be used by existing companies, which have been operating in the field for a long time. It’s great to use this Vision when searching for new development opportunities.
The Series itself contains the following Articles, which are recommended to read in the provided order (as it usually goes with tech teams — from technology to business):
- What is the Level of your Tech Start-up? Part 1/3. Software Technical Architecture (this Post)
- What is the Level of your Tech Start-up? Part 2/3. Software Business Architecture
- What is the Level of your Tech Start-up? Part 3/3. Software Business vs Technical Architecture
Initially, it was decided to share the Insights related specifically to how the Software Technical Architecture Layers intersect with the Marketing/ Sales Opportunities, which developed applications should have. But later on, it became clear that the entire topic shall be split into smaller chunks, making it easier to perceive, going step by step.
The Software Technical Architecture Layers presented in the Article are inspired by Domain-driven Development (DDD), Clean Architecture and Hexagonal Architecture (more info on this is provided below with examples and references).
The Software Business Architecture Layers were identified in an analogous way following the same common principles (“coupling and cohesion”) — this is described in detail in the Article What is the Level of your Tech Start-up? Part 2/3. Software Business Architecture.
But for sure the most interesting results come in the combined 3rd Part — What is the Level of your Tech Start-up? Part 3/3. Software Business vs Technical Architecture.
This Article has three Sections:
- Software Technical Architecture Diagram, AIFORSE Edition — the resulting diagram itself
- Notes to the Diagram — if you feel you’re good at reading diagrams, or you want to use it as is w/o any extra justifications behind it, you can undoubtedly skip this section
- External Sources and References — if you don’t really care what this diagram is based on, as well as other fundings on this topic in the industry, you can skip this section as well
Software Technical Architecture Diagram, AIFORSE Edition
Notes to the Diagram
General Information
I won’t write too much about all the conceivable and inconceivable benefits of layering software applications, but I’ll provide a few of my thoughts on this.
- This is not what you need by default. If you need a quick prototype, or if you’re 547% sure this is a one-time solution, don’t spend your time on layering your code. [Personally, I don’t believe one-time solutions exist at all; by definition “one-time” means it’s going to be run literally just one time, but if you’re not a criminal maniac, you’ll like to test your app at least once before running this for a purpose; which makes this run already not for one time]
- In order to do this, you need domain knowledge, professional experience, and intuition. You need to feel very confident when dividing code into pieces and creating new levels of abstraction. Abstract thinking and the in-built “sense of technical beauty” help much here.
- If you do this, this is an investment, which returns more in a long-time period. Don’t expect this approach will make your life easier, at least not from day 0. You’ll feel that this really works only when you’ll start heavily customize and extend your app.
Software Technical Architecture Layers
Presentation Layer. It’s responsible for letting your application out for external actors. It specifies how one can access the use cases, identified for the app (see the next layer)
- User Interface. The way commonly human users can interact with your application. This can be any type of user interface (UI): Desktop App, Web App, Mobile App, Chatbot, etc.
- API Gateway [REST API etc.]. The way commonly program users can interact with your application. It’s usually one of the standard methods of apps communication: RESTful API, SOAP API, RPC, etc.
Application/ Service Layer. It specifies why one would like to access the domain entities (see the next layer) as it defines all the possible use cases.
- Use Case Interface. The main “contract”, which defines the system capabilities of the application.
- Use Case. The implementation of the Use Case Interface, which however must NOT include any of the Business Logic (see the next layer)
- Dependent Use Case Interface. It specifies the “contract” for the “downstream” use cases — which a current use case depends on; designing an application in such way perfectly disassociates it from the actual implementations of those 3rd party use cases both of which might change with time.
- (3rd Party Application Adapter). The implementation of the Dependent Use Case Interface, which in no way shall contain any of the Business Logic, just objects and/or parameters mapping. [Study more about the “Dependency Inversion Principle”]
Domain Layer. It’s responsible for identifying the “business core” of the application — entities and business logic, specifying what should work and how. It, however, has zero details on how all this is physically stored (see the next layer)
- Domain Entity Interface. The main “contract”, which defines all the types of objects within the specific domain. It’s still a separate story of how domains should be sliced, keeping them at the same time minimal, complete and independent.
- Domain Data Model. The implementation of the Domain Entity Interface, which realizes all the classes, their parameters, and relationships between them.
- Domain Service Interface. The main “contract”, which defines all the methods and service operations, which can be done with, over or in relation to domain entities.
- Domain Business Logic. The implementation of the Domain Service Interface, which realizes all the defined methods.
- Persistence Interface. It specifies the “contract” of the data storage, which is used by the domain model to store data in the physical repository, knowing nothing about any specific data storage implementation. [Study more about the “Dependency Inversion Principle”]
Persistence/ Infrastructure Layer. It defines how application data is stored
- Repository Adapter. The Implementation of the Persistence Interface, enabling storing of domain entities to the physical storage. It converts domain entities objects to/ from the objects, which are stored in the physical storage; designing an application in such way perfectly disassociates domain data model from the repository data model both of which might change with time. Sometimes it’s also called “Data Mapper”.
- Repository Interface. The main “contract”, which defines access to the physically stored data, knowing nothing about any specific domain model implementation.
- Physical Infrastructure. The actual storage for app data.
External Sources and References
Onion Architecture
Onion Architecture consists of multiple concentric layers interacting with each other towards the core that defines the domain.
Onion Architecture Is Interesting
Source: https://dzone.com/articles/onion-architecture-is-interesting
Hexagonal Architecture
The hexagonal architecture, or ports and adapters architecture, is an architectural pattern, which aims at creating loosely coupled application components that can be easily connected to their software environment by means of ports and adapters.
Domain-Driven Design and Hexagonal Architecture with Rails
Source: https://www.youtube.com/watch?v=_rbF97T4480
Hexagonal Architecture Three Principles
Source: https://blog.octo.com/en/hexagonal-architecture-three-principles-and-an-implementation-example/
The Clean Architecture
“The concentric circles represent different areas of software. The outer circles are mechanisms. The inner circles are policies. The overriding rule that makes this architecture work is The Dependency Rule. This rule says that source code dependencies can only point inwards. Nothing in an inner circle can know anything at all about something in an outer circle.”
Source: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
The Clean Architecture
Source: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
Domain-driven Design (DDD)
A Software Development Approach which puts the primary focus on the core domain and its logic with layers on top of it.
DDD and Testing Strategy
Source: http://www.taimila.com/blog/ddd-and-testing-strategy/
Service Layer
Source: https://martinfowler.com/eaaCatalog/serviceLayer.html
Presentation-Domain-Data Layering
Source: https://martinfowler.com/bliki/PresentationDomainDataLayering.html
Domain-driven Design Example
Source: https://www.mirkosertic.de/blog/2013/04/domain-driven-design-example/
Design a DDD-oriented Microservice
Modularizing the Application and Domain Layers
DDD in Practice
Source: https://www.infoq.com/articles/ddd-in-practice
Summary
The provided Software Technical Architecture Diagram, AIFORSE Edition, summarizes all the approaches and principles, provided above, in a single, concise, clear and easy-to-use way.
Create better software better!
