O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Software design with Domain-driven design

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio

Confira estes a seguir

1 de 36 Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Semelhante a Software design with Domain-driven design (20)

Anúncio

Mais recentes (20)

Software design with Domain-driven design

  1. 1. Domain-Driven Software Design PSIA October 23, 2018
  2. 2. Agenda • Physical Architecture • Domain-Driven Software Design • Bounded Context • Entity • Value Objects • Repository • Entities and Optimization
  3. 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. 4. Modular Monolith • Each layer will have a physical server • Requires centralized authentication server • IdentityServer4 is a natural choice
  5. 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. 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. 7. DEMO – IdentityServer4 • Walk-around the quickstart • Using TokenFilter at the server side to refresh session’s token
  8. 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. 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. 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. 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.
  12. 12. Source: http://www.databaseanswers.org/data_models/hotels/index.htm
  13. 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. 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. 15. LABORATORY EXERCISE 2 • Based on the laboratory exercise 1, identify the different bounded contexts of the e-commerce system
  16. 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. 17. Modeling entities • Attributes • Operations (Behaviors)
  18. 18. DEMO • Adding attributes and operations to entities
  19. 19. LABORATORY EXERCISE 3 • Based on the laboratory exercise 1, add attributes and operations to domain models (entities)
  20. 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. 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. 22. DEMO • Creating value type objects
  23. 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
  24. 24. DEMO • Repository
  25. 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. 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. 27. Use try/catch Statement • Use the try/catch statement in all database operations • Return the error information, preferably with value object
  28. 28. Optimizing Query • Retrieve only the fields needed in the query vs vs
  29. 29. Optimizing Query • Retrieve only the fields needed in the query
  30. 30. Optimizing Query • Retrieve only the fields needed in the query
  31. 31. Optimizing Query • Retrieve only the fields needed in the query
  32. 32. Avoid Retrieving Related Collections • Each collection will have its own query
  33. 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. 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
  35. 35. QUESTION AND ANSWER
  36. 36. THANK YOU

×