Architecture Overview of

Provident Fund Management

Md. Mojammel Haque
Domain Driven Design
Where is a car on the left or on the right?
Domain Driven Design
Difference is that Car is not just a huge collection of
parts.
Car is not even a collection of parts which need to fit
together.
Car is much more than that.
A good Car starts with vision and carefully written
specifications, and it continues with design and with
testing.
The design is modified based on the testing results.
Only after that each part could be assembled
together.
Software development is similar, we cannot just sit
down and type code.


Core definitions:
What is Domain Driven
Design
Domain Driven Design is a collection of patterns
and principles that help you to build applications
that reflect the domain by meet the requirements of
business.



Core definitions:
What is Domain
The business process that being automated
is the domain of the software e.g. E-
Commerce System.




Core definitions:
What is Sub-Domain
Sub-Domain
If a domain is too large then it can be split into
multiple pieces. In this case each piece is called
sub-domain.




Core definitions:
What is Model
Model / Domain Model:
The model is the internal representation of target domain.
A model is an essential part of software design.
We need it in order to be able to deal with complexity.



Core definitions:
What is Ubiquitous Language
Ubiquitous Language:
A language structured around the domain
model and used by all team members to
connect all the activities of the team with the
software.





Core definitions:
What is Context & Bounded Context
Core definitions:
What is Context & Bounded Context
Context
Statement about a domain is known as context.
Each model has its own context.
Example:
E-Commerce system is an example of shopping context.
Bounded Context
If we are involve with large enterprise application then we
need to deal with multiple model so we will have multiple
context.
Each pieces of context is called Bounded context.
Example:
In an e-Commerce system initially you can tell it is an
application of shopping context.
But if you look more closely, you will see there are other
contexts too. Like: Inventory, Delivery, Accounts etc.




Basic Building Block of Domain Driven
Design
Basic Building Block - Entity

Basic Building Block - Entity
Entities are classes where the instances are globally
identifiable and keep the same identity for life.
There can be change of state in other properties, but
the identity never changes.
The key defining characteristic of an Entity is that it
has an Identity it is unique within the system, and
no other Entity, no matter how similar is, the same
Entity unless it has the same Identity.


Basic Building Block - Entity

Basic Building Block Value Object

Basic Building Block Value Object
An object that contains attributes but has no conceptual identity.
They should be treated as immutable.
Example:
When people exchange dollar bills, they generally do not
distinguish between each unique bill; they only are concerned
about the face value of the dollar bill.
In this context, dollar bills are value objects.
However, the Federal Reserve may be concerned about each
unique bill; in this context each bill would be an entity.

Basic Building Block Value Object

Basic Building Block Aggregate & Aggregate
Root

Basic Building Block Aggregate & Aggregate
Root
A collection of objects that are bound together by a root entity, otherwise known
as an aggregate root.
The aggregate root guarantees the consistency of changes being made within
the aggregate by forbidding external objects from holding references to its
members.
Aggregates can also be seen as a kind of bounded context, giving the root
entity and the whole object graph a context in which they are used.
Example:
In E-Commerce system:
Color, Size and Price are related with Product. If we get product it will be
possible to get color, size and price information related to the price. So in
this context product is the aggregate of color, size and price.
Quantity, Order Line, Shipping Address, Item Price are related with Order.
If we get any order we will also get above things. So Order is the
aggregate of quantity, line, address and price.
Customer will provide his/her credit card, address, postal code. So in the
customer context customer will be the aggregate of credit card, address
and postal code.



Basic Building Block Repositories

Basic Building Block Repositories
Repositories save and retrieve Entities or
Aggregates to or from the underlying storage
mechanism.
Repositories are part of the domain model, so
they should be database vendor independent.
Repositories can use DAO's(Data Access
Objects) for retrieving data and to encapsulate
database specific logic from the domain.

Basic Building Block Repositories

Basic Building Block Factories

Basic Building Block Factories
Factories manage the beginning of the life cycle
of some aggregates.
This is an application of the GoF factory or
builder patterns.
Use factories pragmatically.
Remember that factories are sometimes very
useful, but not essential.

Basic Building Block Factories
public class DapperContextFactory:IDataContextFactory,IDisposable
{
private IDapperContext dataContext;

public IDapperContext Context()
{
return dataContext ?? (dataContext = new DapperContext());
}

public void Dispose()
{
if (dataContext != null)
dataContext.Dispose();
}
}

Basic Building Block Services

Basic Building Block Services
When an operation does not conceptually
belong to any object.
Following the natural contours of the problem,
you can implement these operations in services.

Provident Fund Architecture
Infrastructure
Domain Model
Repository.Contracts
Repository
Services
Website
Provident Fund Architecture:
Layer Description
Infrastructure Layer:
This layer acts as a supporting library for all the other layers.
It provides communication between layers, implements
persistence for business objects, contains supporting
libraries for the user interface layer, etc.
Domain Layer:
This layer contains information about the business domain.
The state of business objects is held here. Persistence of the
business objects and possibly their state is delegated to the
infrastructure layer.
Repository.Contracts
Contains all repository interfaces, context interfaces and
UnitOfWork interface.

Provident Fund Architecture:
Layer Description
Repository:
Contains the implementations of all interfaces of
Repository.Contracts

Services
Contains View Models, mapping between
Domain Models and View Models, faades

Website
Contains Ioc, Controller classes and Views.
Layer Description: Infrastructure
Infrastructure/BusinessRule:
Check the validity of a domain entity prior to
persistence.
This class will store a rule and related entity
property.
The class will populate a collection of broken rules
before saving an entity.
Infrastructure/Entity:
Though all entities will share the same validation
mechanism, you will create a Layer Super type i.e.
base entity class that will inherit by all other domain
entities to provide the infrastructure for checking
domain validity. The code for the Entity class will
contain the logic for validating an entity.


Layer Description: Infrastructure
Infrastructure/IAggregateRoot
Aggregate root define the entry point into a logical
aggregation of related domain entities.
The Aggregate root is to ensure that the aggregation
remains in a consistent and valid state.
The entity that acting as aggregate root will also
have a corresponding repository to enable data
persistence and retrieval.



Layer Description: Infrastructure

Infrastructure/ValueObjectBase
Value objects are objects that do not have an identity
and should be immutable.
Not all objects in the domain model will be modeled as
entities some will be modeled as Value objects.
Though value objects are immutable and cannot be
Changed so Value objects will inherit from a separate
base type named ValueObjectBase.

Infrastructure/ ValueObjectIsInvalidException:
If a value object is not created in a valid state, an
exception will be thrown so create this.

Encryption/ Md5Encrypt:
MD5 data encryption algorithm

Layer Description: Model
Person
Person Domain model that will inherited by
Entity and IAggregateRoot.
This will contain all properties of Person
domain entity and Validate() method and all
other domain logic related to person domain.

PersonBusinessRule
Provide individual validation rule for individual
property of domain model.


Layer Description: Repository.Contracts

Context/IDapperContext
Interface for provide database context using
Dapper

Context/IDataContextFactory
Interface for provide factory of dapper database
context.

UnitOfWork/IUnitOfWork
Interface for provide Unit of work pattern.



Layer Description: Repositories
Repositories/IReadOnlyRepository
Interface for provide Repository pattern
(contains the signatures of Read only methods
i.e. Get(), GetById(id) etc.)

Repositories/IRepository
Interface for provide Repository pattern
This will inherit IReadonlyRepository.

Repositories/IPersonRepository
Interface for the repository of our person domain
model.


Layer Description: Repository

Context/DapperContext
Provide the Connection with Sql server database.


Context/DapperContextFactory
Provide new instance of DataContext to Unit Of
Work when exiting context instance remain null.


Layer Description: Repository

UnitOfWork/UnitOfWork
Commit / rollback any transaction that defined
inside repository.


Repositories/DapperRepository
Base class of all Repositories

Repositories/PersonRepository
Repository class for Person Domain Model


Layer Description: Services

ViewModel/PersonView
Model class for View Person domain model i.e. it will
use to display person information in UI.

Mapping/Profiles/PersonToPersonViewProfile &
Mapping/Profiles/PersonViewToPersonProfile

Sometime we need to map all properties of Domain
Model and View Model (in case of complex entities)
i.e. Property to Property mapping between Domain
Model and View Model. In that case we have to
create these profiles.


Layer Description: Services

Mapping /Extensions/PersonExtension
Map domain model and view model class
(Individual class and collections).

Mapping /AutoMapperBootStrapper
Call the defined profiles during Bootstrap the
application

Layer Description: Services

Exceptions/InvalidPersonException
Exception class that will be thrown when
validity of Person class will be failed.

Facades/IPersonsFacade
Interface for Person Faade class which
contains all the method signatures that will be
used in Person Faade.

Layer Description: Services
Facades/PersonsFacade
Contains required methods for insert /updte
/delete /GetById /Getall methods. Here we used
Repository to execute transactions and unit of
work to commit or rollback those transactions.
Note:
If we have multiple transactions in a single
method then we will call all the transactions first
then finally we will call commit () method of unit
of work. So all the transactions will be commit or
rollback at the same time and there is no chance
to miss data because when any error will be
found then all the transaction will be rolled back.
Inside faade before any transaction statement
execution (DML Operation) we will call validate
method related to the domain model of that DML.

Layer Description: Website
DependencyResolution/IoC

In many places we inject interfaces instead
of concrete classes i.e. injected
dependencies. e.g. Repositories,
UnitOfWork, PersonFacade,
PersonController.
During bootstrap the application we have to
resolve these dependencies. In this class we
will resolve these dependencies.

Layer Description: Website
Controllers/PersonController
Call all the methods of faade and after
executing these methods return different actions
to view class.

Controllers/PersonAsyncController
Call all the methods of faade and after
executing these methods return different actions
to view class.
(It will contain and return all asynchronous
methods)

Layer Description: Website.Tests
Controllers/PersonControllerTest
Unit test the Person controller based on different
test case.

** Though we pass dynamic parameter to our
repository so our stored procedures
parameters and domain models property
should be same name and same sequence of
declaration.





Thank You