Understanding DevOps Principles and CI/CD

Although many people define DevOps as a process, the more you work with it, the better you understand it as a philosophy. This chapter will cover the main concepts, principles, and tools you need to develop and deliver your software with DevOps.

By considering the DevOps philosophy, this chapter will focus on service design thinking, that is, keeping in mind that the software you design is a service offered to an organization or part of an organization. The main takeaway of this approach is that the highest priority is the value your software gives to the target organization. Moreover, you are not just offering working code and an agreement to fix bugs but also a solution for all the needs that your software was conceived for. In other words, your job includes everything it needs to satisfy those needs, such as monitoring users’ satisfaction and quickly adapting the software when the user needs change, due to issues or new requirements...

Before you begin: join our book community on Discord

Give your feedback straight to the authors themselves and chat to other early readers on our Discord server (find the "software-architecture-csharp-12-dotnet-8" channel under EARLY ACCESS SUBSCRIPTION).

https://packt.link/EarlyAccess

This chapter is dedicated to a modern software development technique called domain-driven design (DDD), which was first proposed by Eric Evans (see, Eric Evans, Domain-Drive Design). While DDD has existed for more than 15 years, it has achieved great success in the last few years because of its ability to cope with two important problems.The main problem is modeling complex systems that involve several domains of knowledge. No single expert has in-depth knowledge of the whole domain; this knowledge is instead split among several people. Moreover, each expert speaks a language that is specific to their domain of expertise, so for effective communication between the experts and the development...

Technical requirements

This chapter requires Visual Studio 2022 free Community Edition or better with all the database tools installed.All the code snippets in this chapter can be found in the GitHub repository associated with this book, https://github.com/PacktPublishing/Software-Architecture-with-.NET-8-4E.

What are software domains?

As we discussed in Chapter 2, Non-Functional Requirements, and Chapter 3, Documenting Requirements, the transfer of knowledge from domain experts to the development team plays a fundamental role in software design. Developers try to communicate with experts and describe their solutions in a language that also domain experts and stakeholders can understand. However, often, the same word has a different meaning in various parts of an organization, and what appear to be the same conceptual entities have completely different shapes in different contexts.For instance, in our WWTravelClub use case, the order-payment and packages-handling subsystems use completely different models for customers. Order-payment characterizes a customer by their payment methods, currency, bank accounts, and credit cards, while packages-handling is more concerned with the locations and packages that have been visited and/or purchased in the past, the user’s preferences, and their...

Understanding domain-driven design

According to DDD, we should not construct a unique Domain Model that projects into different views in each application subsystem. Instead, the whole application domain is split into smaller domains, each with its own data model. These separate domains are called Bounded Contexts. Each Bounded Context is characterized by the language used by the experts and used to name all the domain concepts and operations. Thus, each Bounded Context defines a common language used by both the experts and the development team called a Ubiquitous Language. Translations are not needed anymore, and if the development team uses C# interfaces as bases for its code, the domain expert is able to understand and validate them since all the operations and properties are expressed in the same language that’s used by the expert.Here, we’re getting rid of a cumbersome unique abstract model, but now we have several separate models that we need to relate somehow. DDD...

Entities and value objects

DDD entities represent domain objects that have a well-defined identity, as well as all the operations that are defined on them. They don’t differ too much from the entities of other, more classical approaches. Also, DDD entities are the starting point of the storage subsystem design.The main difference is that DDD stresses their object-oriented nature, while other approaches use them mainly as records whose properties can be written/updated without too many constraints. DDD, on the other hand, forces strong SOLID principles on them to ensure that only certain information is encapsulated inside of them and that only certain information is accessible from outside of them, to stipulate which operations are allowed on them, and to set which business-level validation criteria apply to them.In other words, DDD entities are richer than the entities of record-based approaches.In other approaches, operations that manipulate entities are defined outside of them...

Classic Layers architecture

In this and in the sections that follows we will describe some of the patterns and architectures that are commonly used with DDD. Some of them can be adopted in all projects, while others can only be used for certain Bounded Contexts.We start with classic Layers architecture since it is simpler to understand, and then, in the next section, we will describe the more sophisticated Onion architecture.The functionality of each application can be classified into three groups:

1. Handling the interaction with the user.
2. Performing business related processing.
3. Interacting with the storage engine.

Each of the above groups uses a different language, and different technologies. The first group uses the language of the target users and user interface technologies, the second group uses the language of the domain expert and is focused on application domain modelling, and the third group uses both language and technologies related to databases.Classic Layers architectures...