Domain Driven Design C# Example Software Architect With
Domain driven design en vernieuwende database technologien. WebAssembly is a platform for running binary compiled code, for example C# CLR. Blazor WebAssembly is a framework for writing frontend applications with HTML/CSS and C# in browsers supporting WebAssembly. It is developed with high speed by Microsoft and by open-source communities. Alexey is also a contributor to several open source projects, such as RestSharp and MassTransit, and is the organizer of the DDD Norway meetup.Blazor WebAssembly 3.2.0 has been shipped by Microsoft in May 2020, but so far there are lots of articles for this framework. Alexey Zimarev is a software architect with a present focus on domain models, Domain-Driven Design (DDD), event sourcing, message-driven systems and microservices, coaching, and mentoring.
In this article we propose a code architecture for Blazor WebAssembly with DDD approach.Usual DDD code architecture composes of 4 layers:Architecture diagram is shown on Figure 1. DDD also introduces a way of classifying objects into Entities, Value Objects, Services, Factories and Aggregates. Each Bounded Context has internal model and explicit relationships with other Bounded Contexts.
Infrastructure is a layer that contains databases, migrations, repositories, I/O logic and integrationsFigure 1 Domain-driven design usual architecture.Domain is the most important layer in DDD approach. Application takes data from infrastructure and executes logic on Domain with it. Command handlers can manipulate data in application and Query handlers can only get data and cannot change anything in the underlying state. Commands and Queries are parameter classes that are sent to Application and handled by Command or Query handler. User interface only knows about Application and usually uses DTOs to communicate with Application layer.Application layer contains DTOs, Commands, Queries, Command handlers, Query handlers and Validators.
Usually each Bounded Context contains Entities, Services, Factories, Value Objects, Aggregates, Validators, Enums and Helpers (i.e. Communication between different Bounded Contexts is done with Shared Bounded Contexts. Each Bounded Context is a separate module with separate logic and code.
This architecture is shown on Figure 3.Figure 3 Blazor WebAssembly simple architecture.Proposed domain-driven design architecture for Blazor WebAssembly applicationsWhile merging those two architectures into one we can propose architecture presented on Figure 4. This means that backend consists of Server and Shared and frontend consists of Client and Shared. Shared project DDLs are copied both to browser client machine and hosting server. Both Client and Server depend on Shared project and share its code base. Example usual architecture for Domain layer is shown on Figure 2.Figure 2 Usual architecture in domain-driven architecture.When creating Blazor WebAssembly application in Visual Studio we already have three projects: Client, Server and Shared. Also both contexts communicate through Shared Bounded Context.
Backend consists of all layers except Blazor Client. All previous DDD layers are now dependent on adequate Shared layers. The Shared layer was decomposed into two layers: Shared Application and Shared Domain.
Contains code used both in Blazor Client and Application: Contains code used both in Blazor Client and Domain: Doesn’t contain Entities and Aggregates because Client logic should only use DTOs and not Domain objects. Blazor Client depends both on Shared Domain and Shared Application because it needs both DTOs, Commands, Queries and Enums.Figure 4 Proposed Blazor WebAssembly architecture.
It should be:Inner namespace naming should be focused on code type that is inside namespace and then on functionality:In each project, there is folder Configurations which holds ProjectNameDependencyInjection.cs. Depends on Shared Domain and Shared Application.Firstly, we set some convention for namespaces naming. Depends on Application and Shared Application. integration logic with external services, Depends on Shared Domain and Domain (using common enums and Entities) Depends on Domain, Infrastructure, Shared Domain, Shared Application.
An example of InfrastructureDependencyInjection.cs code is presented below:On Figure 5 whole solution structure is presented in Visual Studio Solution Explorer. Also adding new client project only requires calling dependent projects dependency injection code. Dependent projects call this code and thanks to it there is no repeated code in the solution.
However, the benefits of separating business processes from technology and sharing certain components between the server and the client causes that the architecture will certainly be appreciated in the case of complex systems. At first glance, the presented architecture may seem complex and complicated for beginner programmers. There is a possibility to create multiple projects in one layer if the code gets very large. More decoupling can be created by adding layers for Shared Components and API Services. Shared part of code was handled by splitting into two layers for more decoupling. Each project name in solution follows namespace convention with name of hold layer and code type in the end.Figure 8 Folder structure of Application and User Interface projects.Presented architecture separates domain logic from all unnecessary distraction code, provides loose coupling and maintains focus on important parts of code.
0 kommentar(er)
