Design : Sample Domain Driven Design Document

AWS : Serverless Computing Service - Lambda

Design : API Design and RAML

Design : Domain Driven Design Concepts and a sample DDD Document

What is Domain Driven Design?

From Martin Fowler's blog : Driven Design is an approach to software development that centers the development on programming a domain model, that has a rich understanding of the processes and rules of domain. 

Any enterprise system can be built on Domain Driven Model comprised of multiple complex domains, so the developer need to understand them well in the language of Business people. 

Lets look into the main terms and definitions: 

• Context  
•  means the circle in which a word or domain decides its meaning. 
• Ex: Inventory, Sales, Billing are different contexts. 
• Domain 
•  is a subject area to which the developer applies program. 
• Ex Order Management, Sales Management, Billing Management 
• Model
• Core Model - is the part of your model where the most business value lies and distill it into the highest priority context.
• The Domain Model is your organized and structured knowledge of the problem. The Domain Model should represent the vocabulary and key concepts of the problem domain and it should identify the relationships among all of the entities within the scope of the domain. 
• A model in DDD can be represented in a variety of formats such as post-it notes or code. Anything that shows domain concepts, relationships, rules, and so on.
• The Domain Model itself could be a diagram, code examples or even written documentation of the problem. The important thing is, the Domain Model should be accessible and understandable by everyone who is involved with the project.
• Examples are a Class Diagram conceptualize the whole domain, for example the class diagram of Order Management System, Insurance Claim Processing System
• Sub-domain
• Domain and Subdomain can be used interchangeably. All domain are child of another domain in real scenario. 
• When we model our domain we might need to split them into sub-domains for easy management
• Bounded Context
• Define boundaries around domain areas (objects) and reflect them in software.
• Any organization serves a main business but has multiple operational divisions like procurement, processing, making, packaging, finance etc., 
• Similarly we separate and group our models into a limit or boundary, they are called as Bounded Context. 
• It makes the modelling easy and makes the management better.
• For example in an divide and Order Management System into Customer, Product, Order, Payment, Billing, Package. 
• Context Mapping 
• Model of the different bounded contexts of the system
• Is a tool that allows you to identify the relationship between bounded contexts and the relationship between the teams that are responsible for them.
• In most of  real scenarios, two different teams working on different bounded contexts might need to create a model which will be same in set of goals.
• There are 7 different ways to do context mapping 
• Partnership - If two models are aligned and dependent on same set of goals, then two teams can mutually understand each other and partner.
• Shared kernel - Two or more models can share same models. It can be a piece of code, API, library.
• Customer Supplier - If two bounded contexts found and have some common model may be one of them would be a supplier and another one would be consumer. Like upstreaming and down-streaming. This can be determined by the discussion between the two different teams.
• Conformist - This is same as Customer Supplier but the upstream BC has no interest in supporting downstream BC, but the downstream BC has to conform the whatever the upstream provides. Example if an organization build a last API system and the downstream is utilizing only one.
• Anticorruption Layer - Another upstream and downstream bounded contexts, but the downstream BC implements a layer between itself and the upstream. The layer interprets the model according to downstream. Use ubiquitous language in this layer. So whenever new changes are made at upstream, the ACL need to be updated without making any changes to downstream BC. 
• Open Host Service & Published Language - Same as upstream and downstream where the upstream will provide a well written document. The downstream will use them, but the upstream does not need the same from downstream.
• Ubiquitous Language
• It is nothing but the common language used for documentation and discussion, between developers and domain experts. 
• It is mandatory to use domain model terms and words instead of developer words. Mix of both business and developer terms can be evolved.
• Entity 
• Similar to objects in classic object-oriented design but with a focus on identity over time.
• An object defined by thread of continuity and identity.
• A train seat in Ticket Booking Service, an order in Order Services examples of entities.
• If two entities have same properties, but different identities, then they are different.
• Value Object
• Immutable entity identified by its attributes.
• It is similar to entity but the difference is  they are immutable and defined by attributes rather than identity. 
• Example if we purchase a water bottle in a shop, all water bottles are same by properties and does not have identity. 
• If two objects have similar properties, they can be considered equal objects.
• Aggregate
• Encapsulates multiple entities and value objects.
• It is nothing but a (parent object) cluster or group of different objects (child entities). 
• The parent  which holds the child entities, called as Aggregate Root 
• Domain Event
• It is nothing but an change in state happened in domain. 
• Any domain event must be captured, persisted in event store and need to be communicated for further processing.
• Domain events may happen with in a bounded context or across multiple bounded context. When an event occurred in a domain it can be informed to other bounded context to complete a eventual business process. 
• Service
• Stateless object which encapsulates domain logic that cannot reasonably put on an entity or value object.
• In DDD services are used to perform domain operations and business rules. 
• When concepts of the model would distort any Entity or Value Object, a Service is appropriate.
• From Evans’ DDD, a good Service has these characteristics:
• The operation relates to a domain concept that is not a natural part of an Entity or Value Object
• The interface is defined in terms of other elements in the domain model
• The operation is stateless
• Repository
• Library for obtaining access to aggregates.
• In DDD, repository is an object that participates in domain but really abstracts away the storage (persistence) and infrastructure details.
• They perform lookup and save, and they are not same as Factory Patterns. In other words they are conceptual set like a collection with fetch and save. 
• Example : NoSQL Repository, SQL Repository
• Factory
• This is a GoF pattern for creating the domain objects. Better implement different Factory objects if we need to create different set of objects
• Module 
• Structure objects on a higher level to reduce cognitive overload.
• Model Integrity Patterns 
•  Ways to model the connections between multiple bounded contexts
• CQRS
• When we decompose a big monolithic applications or building microservices, it is recommended to separate the query services (which fetch data from storage) and command services (which create, modify and delete data in storage). 
• When the two or more services separated and using single database, we need to check how to scale out database and also share the database across them. 

Microservcies: Database patterns for Microservices

 

When we design microservices architecture, the biggest challenge is how do we manage the data persisted, consistency, availability, scalability when business grows and accuracy at any time.

Unlike the monolithic applications where data is strictly have the ACID properties, microservices need different strategy and design to meet the real need of microservices architecture. The transaction management cannot be guaranteed in microservices architecture considering the decomposed components and number of nodes of applications services running.  

So here are recommended database design patterns (solutions to popular problems).

1. Database per service

2. Shared Database

3. SAGA

4. API Composition

5. CQRS

6. Domain Event

7. Event Sourcing

Lets discuss each one of them in detail.

1. Database per services: 

If we are on Domain Driven Methodology and all our business design and system design is based on Domain Driven Methodology, then we can prefer this option. Creating own database for each API, so no other services can directly access this database. Only through the API this database can be accessed and data manipulations can be performed. 

This is called as Data As Service. Considering the database we wanted to use in enterprise we make decision.

 This is not suitable for larger enterprises like Banking and Financial Services, Insurance Companies because they still rely on RDBMS systems and need ACID properties. So they might different strategies. 

When we building this Data As a Service, there are other issues design issues need to be assessed example Boundary Context. 

 

AWS : VPC and Subnet Selection : IPV4 and IPV6

What is VPC? Why do we need? 

VPC is better knows as Virtual Private Cloud, a virtual private network where you can create your AWS resources S3, EC2 etc., It is isolated virtual network defined by you. 

Also you have privilege to: 

• Choose your own IP address range
• Choose your gateways
• Configure route tables
• Add subnets
• And create VPN connection 
• ACL - Access Control Lists

You must have and default VPC, otherwise you cannot create any AWS resources. Its is like an Data Center without networking. You can access any resource within this VPC from public internet through Internet Gateway. Route tables enables router which routes the traffic from public internet to resources, between resources, etc.,

You can create custom VPC and configure if you do not want to use default VPC. Else you can edit the default VPC and configure according to your needs.

They are highly scalable and without any bandwidth limitations.

Using ACLs and Security Groups you can control your inbound and outbound traffic. ACLs for subnets and Security Groups for instances.

What is Subnet? How to configure?

It is just range of IP addresses within your VPC. You can create any resource and it will have the IP address assigned to it and within the Subnet range.  By  editing CIDR IPV4 or IPV6 you can increase IP address range. See below for detailed explanation. 

Subnet Selection : IPV4

When we work on AWS, we all must come across a mandate step, that is defining our subnets and setting subnet ranges based on our required IP addresses needed for our components with in the VPC. Here let us see how to choose Subnet and range. 

Lets define Subnet: What is Subnet? 

Subnets are part of available networks within the Availability zone. Each VPC has its own isolated virtual private networks which are parts of available network addresses with-in the availability zone. The subnets cannot span across multiple availability zones.

Here we will see how to choose the subnet and define its range.

When we create VPC,  we have to choose the Subnet block either in IPV4 block or IPV6 block. We will discuss the differences between IPV4 and IPV6 later. Let us look at the IPV4 block now. 

Here are the default options 10.0.0.0/24. 

Now lets decode the 10.0.0./24. 

IPV4 has the address ranges of 2^32 it is equal to 4,29,49,67,296 different IP addresses. 

If we define 10.0.0.0/0 -  it means 32-0 = 32, so 2^32 = 4,29,49,67,296 addresses with in the VPC. But we are not going to have such big number of AWS Services or  EC2 instances with-in our VPC. So we are going to have less number of IP addresses. 

If we want 16 addresses in our VPC, we have to go for 10.0.0.0/28 it means, 32-28=4, 2^4=16. So we will be having the 16 IP addresses range. 

OK that's cool. What will be my IP addresses.

 If we have chosen, 10.0.0.0/28, then it is 32-28=4, 2^4=16, ranges from  10.0.0.0 to 10.0.0.15. 

If we have chosen, 10.0.0.0/24, then it is 32-24=8, 2^8= 256, ranges from 10.0.0.0 to 10.0.0.255. 

Lets see what happen is the range is beyond 256. Lets choose, 10.0.0.0/16.

32-20=12, 2^16= 4096, ranges from 10.0.0.0 to 10.0.15.255. 

Let's see if we have chosen 10.0.0.0/16, 32-16=16, 2^16=65536, ranges from 10.0.0.0 to 10.0.255.255.

Can we have only one IP address in my VPC?

Yes it is possible. Give 10.0.00/32, 32-32=0, 2^0=1, ranges from 10.0.0.0 to 10.0.0.0. 

IPV6 Subnet:

If you want to set bigger range of IP addresses, then go with IPV6, where you can set 2^64  

Quick Summary on Lombok and MapStruct

 

Lombok

@Data

@AllArgsConstructor

@RequiredArgsConstructor

@NoArgsConstructor

@Getter

@Setter

@Builder

And Special 

@Singular

@NonNull

@Cleanup

@Value

@SneakyThrows

@Log

@With

MapStruct

Multi-layered applications often require to map between different object models (e.g. entities and DTOs). Writing such mapping code is a tedious and error-prone task. MapStruct aims at simplifying this work by automating it as much as possible.

In contrast to other mapping frameworks MapStruct generates bean mappings at compile-time which ensures a high performance, allows for fast developer feedback and thorough error checking.

1. public class Car {
2.  
3. private String make;
4. private int numberOfSeats;
5. private CarType type;
6.  
7. //constructor, getters, setters etc.
8. }

1. public class CarDto {
2.  
3. private String make;
4. private int seatCount;
5. private String type;
6.  
7. //constructor, getters, setters etc.
8. }

Here we define the Mapper. So after compilation the carToCarDto method is implemented as simple java code.

1. @Mapper 1
2. public interface CarMapper {
3.  
4. CarMapper INSTANCE = Mappers.getMapper( CarMapper.class ); 3
5.  
6. @Mapping(source = "numberOfSeats", target = "seatCount")
7. CarDto carToCarDto(Car car); 2
8. }

How to add AnnotationProcessor in gradle.

https://tomgregory.com/annotation-processors-in-gradle-with-the-annotationprocessor-dependency-configuration/