Solution Architecture with .NET E-Book

Jamil Hallal

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 241

Veröffentlichungsjahr: 2021

Beschreibung

Understanding solution architecture is a must to build and integrate robust systems to meet your client’s needs. This makes it crucial for a professional .NET software engineer to learn the key skills of a .NET solution architect to create a unique digital journey and build solutions for a wide range of industries, from strategy and design to implementation. With this handbook, developers working with the .NET technology will be able to put their knowledge to work.

The book takes a hands-on approach to help you become an effective solution architect. You’ll start by learning the principles of the software development life cycle (SDLC), the roles and responsibilities of a .NET solution architect, and what makes a great .NET solution architect. As you make progress through the chapters, you’ll understand the principles of solution architecture and how to design a solution, and explore designing layers and microservices. You'll complete your learning journey by uncovering modern design patterns and techniques for designing and building digital solutions.

By the end of this book, you'll have learned how to architect your modern web solutions with ASP.NET Core and Microsoft Azure and be ready to automate your development life cycle with Azure DevOps.

Leseprobe

Solution Architecture with .NET

Learn solution architecture principles and design techniques to build modern .NET solutions

Jamil Hallal

BIRMINGHAM—MUMBAI

Solution Architecture with .NET

Copyright © 2021 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Aaron Lazar

Publishing Product Manager: Ashish Tiwari

Senior Editor: Nitee Shetty

Content Development Editor: Rosal Colaco

Technical Editor: Karan Solanki

Copy Editor: Safis Editing

Project Coordinator: Deeksha Thakkar

Proofreader: Safis Editing

Indexer: Tejal Daruwale Soni

Production Designer: Shankar Kalbhor

First published: July 2021

Production reference: 1230721

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80107-562-6

www.packt.com

This book is dedicated to my family, with a special feeling of gratitude to my loving parents, who always supported me and taught me to be an independent and determined person. To my friends, colleagues, and reviewers who inspired me and helped me improve the content of the book. To Kathi, the love of my life, for her enduring encouragement during the writing of this book.

– Jamil Hallal

Contributors

About the author

Jamil Hallal is a results-driven .NET solutions architect with a strong track record of designing and developing enterprise software solutions that dramatically increase organizational effectiveness. He is certified as a Microsoft Certified Professional, designing and developing enterprise applications. He has extensive experience in building large-scale .NET web solutions, process automation, SharePoint portals, business intelligence and data analytics solutions, document management and archiving, microservices and service-based applications, and AI solutions, with a career spanning over 15 years in various industries.

About the reviewer

Gosia Borzecka is a Microsoft AI MVP and a modern workplace consultant at Avanade.

She is a full-stack .NET and React developer with Office 365 experience. For the last 2 years, she has been interested in AI and machine learning (and Python!), and in her day job, she helps customers bring AI and ML models into the modern workplace.

Gosia is also an international speaker and co-leader of NottsDevWorkshop, where she has organized a few AI/Office 365 Bootcamps. She also helps children learn about programming and new technology as a volunteer in local schools as a STEM Ambassador.

Table of Contents

Preface

Section 1: Understanding the Responsibilities of a Solution Architect

Chapter 1: Principles of the Software Development Life Cycle

Understanding the software development life cycle

Exploring the different SDLC stages

Planning and requirement analysis

Defining requirements

Architectural design

Software development

Testing

Deployment and maintenance

Getting familiar with the popular SDLC models

The Waterfall model

The Agile model

The Spiral model

The DevOps model

Choosing the right model

Summary

Chapter 2: Team Roles and Responsibilities

Exploring the development team hierarchy

The project manager – the godfather

The functional analyst – the explorer

The solution architect – the game changer

The development lead – the tech-savvy one

Software developers – the masters of magic

Quality assurance – the quality guards

Highlighting the five key attributes to consider when assembling a team

Building a great team culture

Establishing development standards and best practices

Equipping the team with the right tools

Maintaining continuous communication

Helping developers grow professionally

Summary

Chapter 3: What Makes an Effective Solution Architect?

What is solution architecture?

Exploring the personality traits and skills of an effective architect

Leading by example

Displaying outstanding communication skills

Possessing deep analytical skills

Showcasing brilliant project and resource management skills

Exhibiting patience with others

Working collaboratively

Demonstrating influencing and negotiation skills

Possessing a wide range of technical expertise

Breaking down problems efficiently

Being pragmatic

Taking a look at the common pitfalls for architects

The enterprise architect versus the technical architect versus the solution architect

Summary

Section 2: Designing a Solution Architecture

Chapter 4: Designing a Solution Architecture

Exploring the key principles of solution architecture

Business principles

Data principles

Application principles

Technology principles

Learning to model software architecture using UML

Component diagrams

Class diagrams

Sequence diagrams

State diagrams

Activity diagrams

Package diagrams

Use case diagrams

Designing architecture with UML

Summary

Chapter 5: Exploring Architecture Design Patterns

Introducing the architectural patterns

Popular architecture patterns

Layered architecture

Presentation architecture

Clean architecture

Microservices architecture

Service-oriented architecture

Exploring additional architecture patterns

The serverless pattern

The client-server pattern

The event-driven pattern

The pipe-filter pattern

Choosing the right patterns

Summary

Chapter 6: Architecture Considerations

Learning about quality attributes

Exploring design quality attributes

Maintainability

Flexibility

Reusability

Integrability

Testability

Understanding runtime quality attributes

Performance

Security

Reliability

Usability

Interoperability

Caching in web applications

Implementing caching in ASP.NET Core

Unified solution for logging and tracing

Planning for deployment and monitoring

Summary

Chapter 7: Securing ASP.NET Web Applications

Introducing key security practices

Authentication

Authorization

Anti-XSS

Cross-Site Request Forgery (CSRF)

Cookie stealing

Overposting

Preventing open redirection attacks

Blocking brute-force attacks

File-upload protection

Preventing SQL injection in ADO.NET and Entity Framework

General security recommendations

Web API security recommendations

Protecting web apps and APIs hosted on Azure

Summary

Chapter 8: Testing in Solution Architecture

Highlighting key testing principles

Exploring the main types of software testing

Unit testing

Integration testing

Regression testing

Smoke testing

End-to-end testing

User interface testing

Acceptance testing

Performance testing

Stress testing

Compliance testing

Disaster recovery testing

Exploring testing in Azure

Summary

Section 3: Architecting Modern Web Solutions with DevOps Solutions

Chapter 9: Architecting Modern Web Solutions with ASP.NET Core and Azure

Exploring the characteristics of modern web solutions

Scalable and cloud-hosted solutions

Modular and loosely-coupled architecture

Automated testing

Traditional and single-page application support

Fast deployment

Progressive web apps with Blazor

Choosing between traditional web apps and single-page apps

Selecting traditional web applications

Choosing single-page applications

Understanding the structure of SPAs with ASP.NET Core

Angular SPAs

React SPAs

Vue SPAs

Exploring Azure hosting recommendations

Summary

Chapter 10: Designing and Implementing Microsoft DevOps Solutions

Exploring Agile planning with Azure Boards

Introducing Work Items

Exploring Boards, Backlogs, and Sprints

Getting started with source control

Scaling Git for enterprise DevOps

Structuring Git repos

Branching strategy with Git

Collaborating with pull requests in Azure repos

Managing packages with Azure Artifacts

Exploring CI/CD with Azure pipelines

Summary

Other Books You May Enjoy

Section 1: Understanding the Responsibilities of a Solution Architect

In this section, we will go through the different phases of the Software Development Life Cycle (SDLC) and we will learn about the differences between the popular SDLC models such as Scrum, Spiral, and DevOps. Then, we will learn about the hierarchy in a typical software development team and what to expect in terms of responsibilities from each member, including a solution architect.

Later in this section, we will explore some fundamental soft skills that every solution architect should have and we will get to know some common pitfalls that should be avoided.

This section comprises the following chapters:

Chapter 1, Principles of the Software Development Life CycleChapter 2, Team Roles and ResponsibilitiesChapter 3, What Makes an Effective Solution Architect?

Chapter 1: Principles of the Software Development Life Cycle

In the modern digital workplace, the role of the .NET solution architect is becoming crucial in the software development life cycle. Having a technology leader and a solution creator who can design and build robust and efficient solutions is a key factor to delivering successful products.

This book will highlight the fundamentals that you need to know, as a .NET professional developer, to become an effective solution architect in this growing and rapidly changing field.

Understanding the concept and principles of the Software Development Life Cycle (SDLC) is a great starting point toward planning a software product. This chapter aims to explain the notion of SDLC, its phases, and modern methodologies.

In this chapter, we will cover the following topics:

Understanding what the SDLC isExploring the different SDLC stagesGetting familiar with the popular SDLC models

By the end of this chapter, you will be able to describe the SDLC stages and explain the difference between the popular SDLC models, such as Scrum, Spiral, and DevOps.

Understanding the software development life cycle

In today's digital world, every company is looking to deliver a good quality software product in a short period, which means the efficiency and the speed of the development team are game changers. To achieve this goal, companies must apply a set of well-defined activities and structured stages that define the software development life cycle, also known as the SDLC.

The SDLC is a methodology of work and best practices that aim to ease the process of software development and make it more efficient, ensuring the final product is delivered on time within the project budget and is totally in line with the expectations of the client.

There are different variations and models of the SDLC, such as the Waterfall model, the Spiral model, and the Agile model. They are popular and widely used by most software development organizations. Selecting the right model depends mainly on the size of the project and other factors. In the following sections, we are going to explore these models in detail to help you decide which model is right for your team and the project.

Here are the six stages that are defined in the SDLC process:

Figure 1.1: The six stages of the SDLC

We have just looked at an overview of the software development life cycle and its importance. In the next section, we will explore the different stages of the SDLC process.

Exploring the different SDLC stages

What are the main activities in the SDLC? No matter which model you choose to follow to implement your product, there are six different stages that are considered as common stages in most of the existing models. However, depending on the model, those stages can be executed sequentially or in parallel. By executing this series of stages, it is expected that you will be able to avoid typical and costly pitfalls and achieve the following goals:

Lower costsImproved overall qualityShortened production timeExcellent customer satisfaction

Let's explore these stages since understanding them is very important to the solution architect, who will be involved with all of them. On the other hand, knowing those stages is necessary to organize and facilitate the development of the product, as well as to make the entire development process more transparent. We'll understand each of them in the following sections.

Planning and requirement analysis

Since the requirements analysis is the first stage, it is the most important and fundamental stage in SDLC. This stage starts by identifying the client's stakeholders, and then conducting several meetings and workshops to define the expectations and gather the requirements.

This stage is performed by the business analyst, the project manager, and the senior technical members of the team. They conduct meetings and workshops with the client to gather all the functional and non-functional requirements, such as the purpose of building the product, what problems it will solve, how it will improve the efficiency of the work, what it will include in terms of functionalities and services, who the target audience or the end user is, identifying the user journeys, detailed use cases and test cases, hardware requirements, backup strategies, and failover processes.

Planning is the process of creating a detailed but high-level plan for how and when each module or task in the project will be developed. The aim is to identify the tasks and their dependencies, along with the expected output of each task. This should be aligned with the client's expectations, as defined in the requirement analysis.

After this stage, everyone in the team should have a clear view of the scope of the project, including its budget, resources, and deadline, as well as possible risks and quality assurance needs. This will be shared with the client to align them with the execution of the project and to give them better transparency.

Let's take a look at the different techniques and activities that we usually use when executing the requirements analysis phases:

Use cases: This is an effective technique that is widely used to capture user requirements. It allows us to identify the possible flow of each feature to be implemented in the system, along with how it will interact with the end users. You may be wondering, how many use cases should I write? This might sound difficult at first, but the simple answer to this question is to make sure that you write down as many use cases as possible, to make sure you cover all possible actions and functionalities that should be included in the system.

The following are the common sections of a use case:

a. Use Case Name

b. Summary Description

c. Actors

d. Pre-Conditions

e. Post-Conditions

f. Level

g. Stakeholders

Business Process Modeling Notation (BPMN): This is used globally to create graphs that describe and document a business sequence using symbols and elements. This technique is recommended if you are implementing business automation processes or the product contains business workflows such as approval cycles.

Here are the basic shapes of BPMN diagrams in Visio:

Figure 1.2: Basic shapes of BPMN diagrams

Unified Modeling Language (UML): UML is used to create flowcharts and diagrams to visualize and document software components, such as classes and interfaces. UML is a good design practice and a very useful technique for creating object-oriented software; it helps software developers model and communicate any complex architectural software design:

Figure 1.3: Sample class diagram

Flowchart technique: This is another graphical representation that's used to describe the different steps of a sequential and logical process flow. In the following diagram, we have a sample flowchart for a checkout process. The green box is the starting point for when the user attempts to add items to the checkout cart before settling the payment and receiving confirmation at the end. The red box represents the end of the process; that is, its completion:

Figure 1.4: Sample flowchart diagram

Data flow diagram (DFD): A diagram is worth a thousand words. You can use a DFD to visually represent the way data flows through a process or service in the system. This diagram is used to identify and describe the input data and how it is moving through the system to reach its storage location and form the output data. Here is a sample DFD diagram describing the flow of the data in a purchase order process:

Figure 1.5: Sample data flow diagram

Role Activity Diagrams (RAD): This is a role-oriented representation of every possible action in the system. It is used to easily describe and visualize the different roles that are involved in executing each process or service in the system. The following is a sample role activity diagram describing an ATM transaction and showing the steps that are accomplished by each key role:

Figure 1.6: Sample role activity diagram

Gantt charts: These are used in project management to assist with planning and scheduling projects of all sizes. They provide a visual representation of tasks, their delivery dates, and the order and dependencies of each task.

This makes the execution plan more simplified and transparent for the client. The following is a sample Gantt chart representing a project plan. The tasks are grouped based on a specific context and linked through the predecessor column, along with the start date and end date:

Figure 1.7: Sample Gantt chart plan

Gap analysis: This is a technique that helps compare the current actual results of the system with what was expected by the client in the early stages of the project. It helps denote any missing strategic capability or feature in the system. It should also recommend ways you can make improvements that will help the client meet their initial targets. The following is a sample template that can be used to conduct a gap analysis exercise:

Figure 1.8: Sample gap analysis template

Building prototypes: Building a mock-up, or a Minimum Viable Product (MVP) model, of the product will give the end users an idea of what the final version of the product will look like once all the features have been implemented. Using this technique, you can identify any feasibility challenges that you may face when you actually implement the product.

While performing your analysis, consider grouping the requirements into the following three categories:

Functional requirements: These represent all the detailed features and functionalities of the system. They are very important for both the development team, to find out what to implement, and the client's stakeholders, to help them align on the final results of the product.Operational requirements: These define the scenarios and the performance measures, along with the associated requirements, that are needed for the product to operate properly in accordance with the client's expectations. This includes the following:

a. Establishing critical and desired user performance

b. Defining constraints

c. Establishing the infrastructure needed

d. Establishing measures of effectiveness

Technical requirements: These describe the technical part that must be fulfilled to easily and successfully deploy the product and make it functional with good performance, as per the client's expectations. This includes the technology that will be used, the technical architecture, the hardware, third-party integration, testing, and deployment plans.

Here are a couple of things that should be considered during this stage:

One of the main challenges in the requirements gathering phase is that each member of the client's stakeholders is seeing the product from his/her point of view. For the success of the project, consider listening and capturing all users' perspectives and document them in user stories or use cases. This will help you identify the full picture of what the product will look like and what it will provide as features.In the first meeting with the client, try to identify the different stakeholders and discuss the scope of work to make it clear for all parties. After that, you will have to meet with all the stakeholders to collect the detailed requirements. During these workshops, make sure you keep all your discussions within the scope set forth. This is important to keep the requirements aligned with the business needs and to avoid adding functionalities that the product was never expected to provide.

So far, we've explored the different activities and techniques we can use for planning and conducting the requirement analysis workshop, which is essential for the success of the project. In the next section, we will learn how to document requirements.

Defining requirements

The next step after completing the requirements analysis workshop is to document all the information that was gathered in the previous step to define the product requirements. Usually, the output result of this activity is the Software Requirement Specification (SRS) document, which consists of all the detailed requirements to be designed and developed during all the phases of the project, from the beginning to its end, until the desired product is delivered. This SRS becomes the requirements contract that will be used to develop the product. It will address all the business needs of your client.

Once the SRS document has been finalized and reviewed by all the parties involved in this project, make sure you send it back to the key stakeholders, or the representatives of the key stakeholders, to sign it. The purpose of signing the SRS is to agree that the requirements that are presented and defined in the document are clear and reflect the business needs, as discussed in the analysis workshop. This formal commitment, which is expressed by all parties involved, will play a crucial role in the project life cycle to ensure that the project will not struggle from scope creep during its implementation.

Important Note:

In project management, scope creep (or requirement creep) refers to a situation where the client is continuously requesting changes and adding new features to the product, even after project kickoff. As a result, the project's scope will continue to grow, which will affect the delivery time and the final cost of the product. This should not occur and to prevent it, you must make sure that all the business needs (that is, the scope of the project) are very detailed and properly defined, and that the client has officially committed to the scope of work.

A basic outline for an SRS document may look like this:

Introduction

1.1 Purpose

1.2 Intended Audience

1.3 Intended Use

1.4 Scope

1.5 Definitions and Acronyms

Overall Description

2.1 User Needs

2.2 Design and Implementation Constraints

2.3 Assumptions and Dependencies

System Features

3.1 Functional Requirements

External Interface Requirements

4.1 User Interfaces

4.2 Software Interfaces

4.3 Hardware Interfaces

Non-Functional Requirements

5.1 Performance Requirements

5.2 Security Requirements

5.3 Software Quality Attributes

Feel free to use this outline and modify it as per your needs, but keep in mind that this document should describe the functionality the product needs to fulfill, along with the technical specifications. Therefore, it should be simple, easy to read, and understand by the project stakeholders. In the next section, we are going to learn about the architecture design phase.

Architectural design

How will we build the product? This a crucial question to answer, especially if you're building a complex or large-scale product that will be used by a wide range of users.

To answer this question, we need to start the architectural design phase, which consists of converting the software specifications that were defined and documented in the previous stages into an abstract design specification plan called the architectural design.

The starting point of this phase is to go through the SRS document and understand every single detail in the requirements. This will help you create the best architecture design, which will ensure you deliver a high-quality product. It is the responsibility of the technical team to document their design in a Design Document Specification (DDS) document. The intended audience of this document is the designers, software developers, and QA testers.