Software
Components’
Architecture
Memi Lavi
www.memilavi.com
Software Component:
A piece of code that runs in a single process
Distributed Systems:
• Composed of independent Software
Components
• Deployed on separate processes
• …or containers
• …or servers
Typical Distributed System
HTTP
Service #1 Service #2
HTTP
HTTP
Service #4 Service #3
Note: This diagram depicts a very simple, non-best-practiced system, for clarity purpose only.
Two Levels of Software Architecture
• Component’s Architecture
• Inner Components
• Interaction between them
• Make the code fast and easy to maintain
Two Levels of Software Architecture
• System Architecture
• Bigger Picture
• Scalable, Reliable, Fast, Easy to maintain
Low Level Discussion Ahead!
Do Not Distance Yourself from the Code
Layers
Layers
• Represent horizontal functionality
- Expose API
Expose User Interface / API UI / SI - JSON Handling
- Auth
- Validation
Execute Logic Business Logic (BL) - Enrichment
- Computations
- Connection Handling
Save / Retrieve Data Data Access Layer (DAL) - Querying / Saving Data
- Transaction Handling
Purpose of Layers
• Forces well formed and focused
code
• Modular
Concepts of Layers
• Code Flow
UI / SI
Business Logic (BL)
Data Access Layer (DAL)
Concepts of Layers
• Code Flow
UI / SI
Business Logic (BL)
Data Access Layer (DAL)
Concepts of Layers
• Loose Coupling
DAL dal=new DAL();
var entity=dal.GetData(101);
Concepts of Layers
• Loose Coupling
IDAL dal=GetDAL();
var entity=dal.GetData(101);
Dependency Injection
Concepts of Layers
• Exception Handling
Business Logic (BL)
MySQLException
Data Access Layer (DAL)
MySQL
Concepts of Layers
• Exception Handling
Business Logic (BL)
MySQLException
DataException
- Analyze Exception
Data Access Layer (DAL) - Write to Log
- Throw Generic Exception
MySQL
Layers vs Tiers
Layers: Tiers:
Component / Service
UI / SI Tier #1
Network
Business Logic (BL) Network
Tier #2
Data Access Layer (DAL) Tier #2
Network
Interfaces
Interface
• A contract
• Declares the signatures of an implementation
The Calculator
The Calculator Without Interfaces
The Calculator Without Interfaces
New Is
Glue
The Calculator With Interfaces
Dependency Injection
Dependency Injection
A technique whereby one object … supplies the
dependencies of another object
Dependency Injection Example
Dependency Middleman
GetInstance Implementation #1
GetInstance Implementation #2
GetInstance Implementation #2
Constructor Injection
Constructor Injection Testing
Dependency Injection
• Not trivial, but…
• Makes the code modular, flexible and easy to maintain
• Give it a try!
SOLID
SOLID
• Coined by Bob Martin in 2000
• Stands for:
• Single Responsibility Principle
• Open/Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle
Single Responsibility Principle
“Each class, module or method should have
one, and only one, responsibility”
Single Responsibility Principle
- What should be written?
Logging Engine
- Where should it be written?
public void Log(string message) public void Log(string message)
{ {
// compose the log message // compose the log message
. var composed=Composer.ComposeMsg(message);
.
. // write the log message to a file
Writer.WriteMsg(composed)
// write the log message to a file }
.
.
.
}
Changes affect only a well defined module
Open / Closed Principle
“A software entity should be open for
extension but closed for modification”
Open / Closed Principle
• Can be implemented using:
• Class Inheritance
• Plug-In Mechanism
• And more…
Make our code as flexible as possible
Liskov Substitution Principle
“If S is a subtype of T,
then objects of type T may be replaced with
objects of type S,
without altering any of the desired properties
of the program”
Liskov Substitution Principle
• Might look similar to Polymorphism…
• Deals with Behavioral Subtyping
Liskov Substitution Principle
Behavior Should Not Be Changed!
ie. Don’t send to archive
Avoid unmaintainable code
Interface Segregation Principle
“Many client-specific interfaces are better
than one general-purpose interface”
Interface Segregation Principle
Interface Segregation Principle
Bloated!
Interface Segregation Principle
Dependency Inversion Principle
Naming Conventions
Naming Conventions
• Define naming rules of code elements
• Classes, Methods, Variables, Constants etc.
• Make the code more readable and easy to understand
• Not enforced by compilers
• Two types:
• Structure (casing, underscores, etc.)
• Content
CamelCase
• First letter of second word onward will be Capitalized
Upper Camel Case:
Lower Camel Case:
• Popular in:
Java, C#, JavaScript, Swift
Recommended for class names in: Python, Ruby
lowercase_separated_by_underscore
• Name contains only lowercase letters
• Words separated by underscore
• Popular in:
Python & Ruby for variable names
CAPITALIZED_WITH_UNDERSCORE
• Name contains only uppercase letters
• Words separated by underscore
• Popular in:
Java, Python & Ruby for naming constants
Hungarian Notation
• Type information is part of the name
• Popular in:
Nowhere. Avoid it.
Content
Class Names Nouns
(DataRetriever, Car, Network)
Methods Names Imperative Verbs
(RetrieveData, Drive, SendPacket)
Naming Convention - Summary
• Always decide on convention
• Better stick to a standard
• Do it ASAP
• Follow it!
Exception Handling
Best Practice #1
• Catch exception only if you have something to do with it
• And no, logging does not count
• Examples:
• Rolling back a transaction
• Retry
• Wrap the exception
Best Practice #2
• Catch only specific exceptions
• Example: SQLException
• Make sure you handle the right exception
Best Practice #3
• Use try…catch on the smallest code fragments possible
• Locate the code fragments that may raise exceptions,
and try…catch on them
Logging
Logging Has Two Purposes
• Track Errors
• Gather data
• Which module is most visited
• Performance
• User’s flow
Log Storage
• Doesn’t really matter
• Files
• Database
• Event Log
Summary
• These are the building blocks of almost any software component
• System Architecture complements it
• Contact me with any question or comment!
