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. Domain-Driven Software
Design
PSIA
October 23, 2018

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.

12. Source: http://www.databaseanswers.org/data_models/hotels/index.htm

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

24. DEMO
• Repository

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

35. QUESTION AND ANSWER

36. THANK YOU