Architecture Overview of Provident Fund Management Md. Mojammel Haque

Domain Driven DesignWhere 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 DomainThe business process that being automated is the domain of the software e.g. E-Commerce System.

Core definitions:What is Sub-DomainSub-DomainIf 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 ModelModel / 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 LanguageUbiquitous 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 ContextContextStatement about a domain is known as context.Each model has its own context.Example: E-Commerce system is an example of shopping context.Bounded ContextIf 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 - EntityEntities 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 ObjectAn 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 RootA 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 RepositoriesRepositories 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 FactoriesFactories 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 ServicesWhen 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

Provident Fund Architecture: Layer DescriptionInfrastructure 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.ContractsContains all repository interfaces, context interfaces and UnitOfWork interface.

Provident Fund Architecture: Layer DescriptionRepository:Contains the implementations of all interfaces of Repository.ContractsServicesContains View Models, mapping between Domain Models and View Models, faadesWebsiteContains Ioc, Controller classes and Views.

Layer Description: InfrastructureInfrastructure/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: InfrastructureInfrastructure/IAggregateRootAggregate 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/ValueObjectBaseValue 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: ModelPerson 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/IUnitOfWorkInterface for provide Unit of work pattern.

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

Repositories/IRepositoryInterface for provide Repository pattern This will inherit IReadonlyRepository.

Repositories/IPersonRepositoryInterface for the repository of our person domain model.

Layer Description: Repository

Context/DapperContextProvide the Connection with Sql server database.

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

Layer Description: Repository

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

Repositories/DapperRepositoryBase class of all Repositories

Repositories/PersonRepositoryRepository 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 /AutoMapperBootStrapperCall 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/IPersonsFacadeInterface for Person Faade class which contains all the method signatures that will be used in Person Faade.

Layer Description: ServicesFacades/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: WebsiteDependencyResolution/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: WebsiteControllers/PersonControllerCall all the methods of faade and after executing these methods return different actions to view class.

Controllers/PersonAsyncControllerCall 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.TestsControllers/PersonControllerTestUnit 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