Why do I need to learn about software design?
What will you do if you are asked to build a house?
You will need to sketch its first and build the house based upon the sketch. Otherwise you may build a house that may collapse in a few weeks or cannot be decorated due to errors.
The situation is similar when you create software. You need to plan how you will build it first by deciding how many components and objects will be used for constructing to solve at least a core problem, what are their responsibility, how they work together, how data will be organized, how data will be flowed within these components, how users will interact with your application, how these components will be deployed.
Software design knowledge will guide you how to do these tasks.
What can I do after finishing learning software design?
You will know how to create a design for an application including static and dynamic structure, data organization, business processing workflows.
Is is really useful? I feel that you can write the code right after having requirements and I am able to refactor my code when needed.
That’s great if you can do it like that. You only need to learn about software design when
(i) you do not know how to write code for a feature or
(ii) you cannot refactor your code because only a small change breaks the whole application or
(iii) you need to write a software system together with 20 other developers and you do NOT know where to begin and how you will integrate results of all the developers into one solution or
(iv) you have a software system that could serve 20 users simultaneously very well but it stops responding when serving 2,000 users simultaneously and you do not know how to fix it.
Alright! What should I do now?
Each application type, such as enterprise systems, games, or intelligent systems, requires specific design knowledge. In this topic, we focus only on the core concepts of software design related to enterprise systems.
First, please read the books below to learn the core concepts and activities of software design as illustrated using the UML language:
After that, please read this book to learn about object-oriented design patterns: Erich Gamma et al (1994). Design Patterns Elements Of Reusable Object Oriented Software. Addison-Wesley Professional. When reading this book, focus first on the Motivation section of each pattern, and feel free to skip any pattern if the problem presented in the Motivation section is not relevant to your situation or does not interest you.
After that, please read the books below to learn about classic design patterns and architectural patterns widely used in enterprise systems:
After that, please read the books below to learn about the core concepts and activities applicable to structured design (i.e., top-down decomposition):
After that, please read the books below to learn about the core concepts and activities applicable to object-oriented design (i.e., bottom-up composition):
After that, please read this book to learn how to design software systematically and how to evaluate a design: David Budgen (2020). Software Design. CRC Press.
After that, please read this book to learn how to create a clean, modular design for an enterprise system: Robert C. Martin (2017). Clean Architecture: A Craftsman’s Guide to Software Structure and Design. Pearson Education.
After that, please read this book to learn about the core concepts of software architecture: Len Bass, Paul Clements and Rick Kazman (2021). Software Architecture in Practice. Addison-Wesley.
After that, please read this book to learn how to document an architecture so that it can be used for communication, software construction and maintenance: Paul Clements et al. (2010). Documenting Software Architectures: Views and Beyond. Pearson.
After that, please read the books below to learn how to create an architecture systematically:
After that, please read this book to learn how to document an architecture for agile projects: Simon Brown (2019). Software Architecture for Developers – Volume 2. 2 – Visualise, Document and Explore Your Software Architecture. Leanpub.
Terminology Review:
- Software Design.
- Design Inputs and Outputs.
- Design Notations.
- User Interface Design.
- Database Design.
- Data Structure Design.
- Algorithm Design.
- Object-Oriented Design.
- Architectures.
- Architecture Design.
- Architectural Styles.
- Architectural Patterns.
- Design Patterns.
- Modeling vs. Designing.
- Analysis Models vs. Design Models.
- Design Phases.
- Design Timing.
- Design Methods.
- “Good” Design: Modularity, Information Hiding, Data Encapsulation, Low Coupling, High Cohesion.
- UML.
- Use Case Diagrams.
- Class Diagrams.
- System Sequence Diagrams.
- Sequence Diagrams.
- Communication Diagrams.
- Activity Diagrams.
- State Diagrams.
- Static Structure.
- Dynamic Structure.
- Design Principles.
- SOLID Principles.
- Cohesion.
- Coupling.
- Design Patterns.
- Software Architecture.
- Architecture Qualities.
- Package Diagrams.
- Component Diagrams.
- Deployment Diagrams.
- Architectural View.
- Architectural Viewpoint.
- The C4 Model.
- Architecture Patterns.
- Enterprise Patterns.
- Row Data Gateway.
- Active Record.
- Data Mapper.
- Table Data Gateway.
- Table Module.
- Transaction Script.
- Domain Models.
- Structured Design.
After finishing software design, please click on Topic 14 – Software Project Management to continue.