SlideShare a Scribd company logo

Software design with Domain-driven design

•
•
Allan Mangune
Allan Mangune

The document discusses domain-driven software design and related concepts. It begins with an overview of monolithic architecture and modular monoliths. It then covers IdentityServer4 for centralized authentication. Next, it defines domain-driven design and the utility of domain models. It discusses ingredients for effective modeling like prototyping and collaboration. It also covers bounded contexts, entities, value objects, and repositories. Finally, it provides tips for optimizing entities and database operations.

1 of 36
Download to read offline
Domain-Driven Software Design PSIA October 23, 2018
Agenda • Physical Architecture • Domain-Driven Software Design • Bounded Context • Entity • Value Objects • Repository • Entities and Optimization
Monolith • User interface and data access code are placed in a single platform • Self-contained and independent from other applications • Three-tier application • User interface • Business layer (Domain) • Data layer (Domain) • If deployed in a single platform, your three-tier app is a monolith Source: https://en.wikipedia.org/wiki/Monolithic_application
Modular Monolith • Each layer will have a physical server • Requires centralized authentication server • IdentityServer4 is a natural choice
IdentityServer4 • OpenID Connect and OAuth 2.0 for ASP.NET Core 2 or up • OpenID Connect – Simple identity layer on top of OAuth 2.0 • Oauth 2.0 – Industry standard for authorization • Centralized login logic for web, native, mobile and services • Single sign on/out • Free and open source Source: http://docs.identityserver.io/en/release/
IdentityServer4 Setup • Start from the scratch • Start from a Visual Studio template • Using the IndentityServer4.Samples or quickstart • https://github.com/IdentityServer/IdentityServer4.Samples • User TokenFilter to refresh session token from the IdentityServer Source: http://docs.identityserver.io/en/release/quickstarts/0_overview.html
DEMO – IdentityServer4 • Walk-around the quickstart • Using TokenFilter at the server side to refresh session’s token
Domain-driven Software Design • Software development approach that evolves around the domain models • Focuses primarily on the core of the domain and its logic • Promotes collaboration between the technical team and domain experts Source: https://en.wikipedia.org/wiki/Domain-driven_design
Utility of a Model in Domain-Driven Design • The model and the heart of the design shape each other • Domain models can be used to communicate with the domain experts • Knowledge generated from collaboration with domain experts are documented in the domain • Models are evolving as more information are gathered Source: Domain-Driven Design by Eric Evans
Ingredients of Effective Modelling • Create the crude prototype early on. • Update the prototype and models as you iterate • Cultivate the language understood by the engineers and domain experts • As you iterate, you will significantly learn about the system being developed. • You will communicate with the domain experts using the domain models you developed. • Develop a knowledge-rich model. • You models will capture system behavior and business rules • Distill the model • Important information are added to the model as more information are gathered. • Brainstorming and experimenting • Use sketches and other techniques when brainstorming to produce the correct idea about the system being developed Source: Domain-Driven Design by Eric Evans
DEMO • Use case – Your team was hired by a customer to develop a hotel reservation system. The customer presented a conceptual model which will serve as a basis for software development project. Based on the conceptual model you will develop the initial set of domain models.
Source: http://www.databaseanswers.org/data_models/hotels/index.htm
LABORATORY EXERCISE 1 • Using the amazon.com website as a reference, create the domain models of a commercial e-commerce system with the following main functionalities • Product catalog • User registration • Checkout process and customer payment system • Wishlist • Review and commenting • Distribution • Procurement • Vendor Payments • Limit your design to domain model names. You will add the attributes and operations later in the class.
Bounded context • Hard to design large domain • Different group of people will have different vocabularies • Large domain models may lead to confusions • Dividing large models into bounded contexts • Explicit interrelationship Source: https://martinfowler.com/bliki/BoundedContext.html
LABORATORY EXERCISE 2 • Based on the laboratory exercise 1, identify the different bounded contexts of the e-commerce system
Entity (aka reference object) • Identity of an object • Object modeling tend to lead us to focus on attributes • Abstract continuity threading throughout a lifecycle • An object must be distinguish from other objects • Most entities in a software are not persons • e.g. City, Car, Lottery Ticket, Bank Transaction etc. Source: Domain-Driven Design by Eric Evans
Modeling entities • Attributes • Operations (Behaviors)
DEMO • Adding attributes and operations to entities
LABORATORY EXERCISE 3 • Based on the laboratory exercise 1, add attributes and operations to domain models (entities)
Value Objects • Objects that do not have conceptual identity • Usually contains attributes only • Used to carry data around • In C#, you can create a value type object with a struct Sources: https://martinfowler.com/bliki/ValueObject.html https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/using-structs
Data Transfer Object (Value object) • Object that carries data among different processes 1 2 Source: https://martinfowler.com/eaaCatalog/dataTransferObject.html Can be a struct Can be a struct
DEMO • Creating value type objects
Repository • Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects. Source: https://martinfowler.com/eaaCatalog/repository.html
DEMO • Repository
Entities and Optimization • Check variable for nullability • Use the transaction for database operations that involve more than one table or row • Use a single DbContext • Optimizing queries
Check variables for nullability • Do not assume that a variable is not null when its instance depends on assignment of method call. • Do not assume that the properties of a variable are not null when their instances also depends on assignment of method calls. • Before using the variable, always check for null using the “if statement” as much as possible. • Return an “Record not found” when needed.
Use try/catch Statement • Use the try/catch statement in all database operations • Return the error information, preferably with value object
Optimizing Query • Retrieve only the fields needed in the query vs vs
Optimizing Query • Retrieve only the fields needed in the query
Optimizing Query • Retrieve only the fields needed in the query
Optimizing Query • Retrieve only the fields needed in the query
Avoid Retrieving Related Collections • Each collection will have its own query
Use AsNoTracking() method • Returned entities from the query will not be cached • DbContext will not track the returned entities, thus improving the performance
Use Transaction • Transaction allows server database operations to be processed in atomic manner. • SaveChanges() by default uses a transaction to commit or rollback database operations. • Preferably, use explicit the transaction from DbContext.Database when updating more than one table or row. Source: https://docs.microsoft.com/en-us/ef/core/saving/transactions
QUESTION AND ANSWER
THANK YOU

More Related Content

Software design with Domain-driven design

  • 2. Agenda • Physical Architecture • Domain-Driven Software Design • Bounded Context • Entity • Value Objects • Repository • Entities and Optimization
  • 3. Monolith • User interface and data access code are placed in a single platform • Self-contained and independent from other applications • Three-tier application • User interface • Business layer (Domain) • Data layer (Domain) • If deployed in a single platform, your three-tier app is a monolith Source: https://en.wikipedia.org/wiki/Monolithic_application
  • 4. Modular Monolith • Each layer will have a physical server • Requires centralized authentication server • IdentityServer4 is a natural choice
  • 5. IdentityServer4 • OpenID Connect and OAuth 2.0 for ASP.NET Core 2 or up • OpenID Connect – Simple identity layer on top of OAuth 2.0 • Oauth 2.0 – Industry standard for authorization • Centralized login logic for web, native, mobile and services • Single sign on/out • Free and open source Source: http://docs.identityserver.io/en/release/
  • 6. IdentityServer4 Setup • Start from the scratch • Start from a Visual Studio template • Using the IndentityServer4.Samples or quickstart • https://github.com/IdentityServer/IdentityServer4.Samples • User TokenFilter to refresh session token from the IdentityServer Source: http://docs.identityserver.io/en/release/quickstarts/0_overview.html
  • 7. DEMO – IdentityServer4 • Walk-around the quickstart • Using TokenFilter at the server side to refresh session’s token
  • 8. Domain-driven Software Design • Software development approach that evolves around the domain models • Focuses primarily on the core of the domain and its logic • Promotes collaboration between the technical team and domain experts Source: https://en.wikipedia.org/wiki/Domain-driven_design
  • 9. Utility of a Model in Domain-Driven Design • The model and the heart of the design shape each other • Domain models can be used to communicate with the domain experts • Knowledge generated from collaboration with domain experts are documented in the domain • Models are evolving as more information are gathered Source: Domain-Driven Design by Eric Evans
  • 10. Ingredients of Effective Modelling • Create the crude prototype early on. • Update the prototype and models as you iterate • Cultivate the language understood by the engineers and domain experts • As you iterate, you will significantly learn about the system being developed. • You will communicate with the domain experts using the domain models you developed. • Develop a knowledge-rich model. • You models will capture system behavior and business rules • Distill the model • Important information are added to the model as more information are gathered. • Brainstorming and experimenting • Use sketches and other techniques when brainstorming to produce the correct idea about the system being developed Source: Domain-Driven Design by Eric Evans
  • 11. DEMO • Use case – Your team was hired by a customer to develop a hotel reservation system. The customer presented a conceptual model which will serve as a basis for software development project. Based on the conceptual model you will develop the initial set of domain models.
  • 13. LABORATORY EXERCISE 1 • Using the amazon.com website as a reference, create the domain models of a commercial e-commerce system with the following main functionalities • Product catalog • User registration • Checkout process and customer payment system • Wishlist • Review and commenting • Distribution • Procurement • Vendor Payments • Limit your design to domain model names. You will add the attributes and operations later in the class.
  • 14. Bounded context • Hard to design large domain • Different group of people will have different vocabularies • Large domain models may lead to confusions • Dividing large models into bounded contexts • Explicit interrelationship Source: https://martinfowler.com/bliki/BoundedContext.html
  • 15. LABORATORY EXERCISE 2 • Based on the laboratory exercise 1, identify the different bounded contexts of the e-commerce system
  • 16. Entity (aka reference object) • Identity of an object • Object modeling tend to lead us to focus on attributes • Abstract continuity threading throughout a lifecycle • An object must be distinguish from other objects • Most entities in a software are not persons • e.g. City, Car, Lottery Ticket, Bank Transaction etc. Source: Domain-Driven Design by Eric Evans
  • 17. Modeling entities • Attributes • Operations (Behaviors)
  • 18. DEMO • Adding attributes and operations to entities
  • 19. LABORATORY EXERCISE 3 • Based on the laboratory exercise 1, add attributes and operations to domain models (entities)
  • 20. Value Objects • Objects that do not have conceptual identity • Usually contains attributes only • Used to carry data around • In C#, you can create a value type object with a struct Sources: https://martinfowler.com/bliki/ValueObject.html https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/using-structs
  • 21. Data Transfer Object (Value object) • Object that carries data among different processes 1 2 Source: https://martinfowler.com/eaaCatalog/dataTransferObject.html Can be a struct Can be a struct
  • 22. DEMO • Creating value type objects
  • 23. Repository • Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects. Source: https://martinfowler.com/eaaCatalog/repository.html
  • 25. Entities and Optimization • Check variable for nullability • Use the transaction for database operations that involve more than one table or row • Use a single DbContext • Optimizing queries
  • 26. Check variables for nullability • Do not assume that a variable is not null when its instance depends on assignment of method call. • Do not assume that the properties of a variable are not null when their instances also depends on assignment of method calls. • Before using the variable, always check for null using the “if statement” as much as possible. • Return an “Record not found” when needed.
  • 27. Use try/catch Statement • Use the try/catch statement in all database operations • Return the error information, preferably with value object
  • 28. Optimizing Query • Retrieve only the fields needed in the query vs vs
  • 29. Optimizing Query • Retrieve only the fields needed in the query
  • 30. Optimizing Query • Retrieve only the fields needed in the query
  • 31. Optimizing Query • Retrieve only the fields needed in the query
  • 32. Avoid Retrieving Related Collections • Each collection will have its own query
  • 33. Use AsNoTracking() method • Returned entities from the query will not be cached • DbContext will not track the returned entities, thus improving the performance
  • 34. Use Transaction • Transaction allows server database operations to be processed in atomic manner. • SaveChanges() by default uses a transaction to commit or rollback database operations. • Preferably, use explicit the transaction from DbContext.Database when updating more than one table or row. Source: https://docs.microsoft.com/en-us/ef/core/saving/transactions