Software Architecture- UNIT IV

Domain-Driven Design

• Domain-Driven Design is a concept introduced by a

programmer Eric Evans in 2004 in his book Domain-Driven

Design: Tackling Complexity in Heart of Software.

• It is an approach for architecting software design by looking at

software in top-down approach.

 What is Domain ?
The word Domain used in context of software development refers

to business.

In the process of application development, term domain logic or

business logic is commonly used.

The business logic of an application is a set of rules and

guidelines that explain how business object should interact with

each other to process modeled data.

 Domain-Driven Design :

software is designed using all latest tech stack and

infrastructure and our software design architecture is fabulous,

but when we release this software in market, it is ultimately end

user who decides whether our system is great or not.

Also if system does not solve business need is of no use to

anyone; No matter how pretty it looks or how well architecture its

infrastructure.
• Domain-driven design talks about two kinds of design tools,

first one is Strategic design tools and another one is Tactical

design tools.

• The programmers or developers usually deal with tactical

design tools but if we have knowledge and a good

understanding of strategic design tools then it will help us in

architecting good software.

 Strategic Design :
The strategic design tools help us to solve all problems that are

related to software modeling.

It is a design approach that is similar to Object-oriented design where

we are forced to think in terms of objects.

Herewith strategic design we are forced to think in terms of a context,

Model, Ubiquitous Language, and Bounded Context. These are

common terms used in strategic Design of Domain-Driven Design.

 Strategic Design :
Let’s understand each one by one.

Context:

Herewith strategic design we are forced to think in terms of a context,

refers to circumstances of an event, incident, statement, or idea.

Model –

It acts as a core logic and describes selected aspects of domain. it is

used to solve problems related to that business.

• Ubiquitous Language –

A common language used by all team members to connect all

activities of team around domain model. Consider it like using

common verbs and nouns for classes, methods, services, and

objects while talking with domain experts and team members.

• Bounded Context –

It refers to boundary conditions of context. It is a description of a

boundary and acts as a threshold within which, a particular

domain model is defined and applicable.

 Tactical Design

Tactical design talks about implementation details i.e., modeling

domain.

It generally takes care of components inside a bounded context. We

might have heard or used stuff like services, entities, repositories,

and factories. They have all coined and made popular by Domain-

Driven design. 
Tactical Design- A navigation map of the language of MODEL-DRIVEN
DESIGN
• Entity –

A programmer who has worked on Object-oriented principles

might be aware of concepts called class and objects. 

• Value Objects –

These are immutable, light-weight objects that don’t have any

identity.
• Services –

A service is a stateless class that fits somewhere else other than an entity or value

object. In short, a service is a functionality that exists somewhere between entities

and values objects but it is neither related to an entity nor values objects.

• Aggregates –

When we have bigger project, object graph becomes big, The bigger object graph

harder it is to maintain it. An aggregate is a collection of entities and values which

come under a single transaction boundary. 

• Factories and Repositories –

Factories and Repositories are used to handle aggregate.

Factories help in managing beginning of lifecycle of aggregates

whereas Repositories help in managing middle and end of

lifecycle of an aggregate.
 Advantages of Domain-Driven Design :

 It improves our craft.

 It provides flexibility

 It prefers domains over interface

 It reduces communication gap between teams through Ubiquitous Language

Disadvantages of Domain-Driven Design :

• It requires a professional who has strong domain expertise

• It encourages team to follow iterative practices

 Continuous Integration Model : 

• Continuous Integration is about how developers integrate code

using a shared repository multiple times a day with the help of

automation.

• Continuous integration (CI) is the practice of automating the

integration of code changes from multiple contributors into a

single software project.

 How to get started with Continuous
Integration
• Continuous integration (CI) is an agile and DevOps best practice where

developers integrate their code changes early and often to the main

branch or code repository. The goal is to reduce the risk of seeing

“integration hell” by waiting for the end of a project or a sprint to merge

the work of all developers. Since it automates deployment, it helps

teams meet business requirements, improve code quality, and increase

security.
 How to get started with Continuous
Integration
• One of the primary benefits of adopting CI is that it will save you time

during your development cycle by identifying and addressing conflicts

early. It’s also a great way to reduce the amount of time spent on fixing

bugs and regression by putting more emphasis on having a good test

suite. Finally, it helps share a better understanding of the codebase

and the features that you’re developing for your customers.

The first step on your journey to continuous integration: setting up
automated testing.

Understanding the different types of tests:

To get the full benefits of CI, you will need to automate your tests to

be able to run them for every change that is made to the main

repository.

There are many types of tests implemented, but it is not necessary to

do everything at once if you’re just getting started. You can start small

with unit tests and work on extending your coverage over time.
Unit tests are narrow in scope and typically verify the behaviour of

individual methods or functions.

Integration tests make sure that multiple components behave

correctly together. This can involve several classes as well as testing

the integration with other services.

Acceptance tests are similar to the integration tests but they focus on

the business cases rather than the components themselves.

UI tests will make sure that the application functions correctly from a

user perspective.
Testing triangle
Unit tests are fast and cheap to implement as they're mostly doing

checks on small pieces of code. On the other hand UI tests will be

complex to implement and slow to run as they often require to get a

full environment started as well as multiple services to emulate

browser or mobile behaviours. Because of that, you may want to limit

the number of complex UI tests and rely on good Unit testing at the

base to have a fast build and get feedback to developers as soon as

possible.
Run your tests automatically:

To adopt continuous integration, you will need to run your tests on

every change that gets pushed back to the main branch. To do so,

you will need to have a service that can monitor your repository

and listen to new pushes to the codebase. There are many

solutions that you can choose from both on-premise and in the

Cloud.
In the past, you typically had to install a separate CI server like

Bamboo or Jenkins, but now you can find solutions on the Cloud

that are much simpler to adopt. For instance, if your code is hosted

on Bitbucket Cloud you can use the Pipelines feature in your

repository to run tests on every push without the need to configure

a separate server or build agents, and with no restriction on

concurrency.
Use code coverage to find untested code:

Once you adopt automated testing it is a good idea to couple it

with a test coverage tool that will give you an idea of how much of

your codebase is covered by your test suite.

It is good to aim a coverage above 80% but be careful not to

confuse high percentage of coverage with a good test suite. A code

coverage tool will help you find untested code but it is the quality

of your tests that will make the difference at the end of the day.
Refactoring is an opportunity to add tests:

If you are about to make significant changes to your application

you should start by writing acceptance tests around the features

that may be impacted. This will provide you with a safety net to

ensure that the original behavior has not been affected after you've

refactored code or added new features.

Integrate early and often

Keep the build green at all times

Write tests as part of your stories

Write tests when fixing bugs

CI will enable your QA Engineers to scale quality

Continuous integration in five steps

Start writing tests for the critical parts of your codebase.

Get a CI service to run those tests automatically on every push to

the main repository.

Make sure that your team integrates their changes everyday.

Fix the build as soon as it’s broken.

Write tests for every new story that you implement.

Features –

 Developers manage code on a shared repository.

 After compilation, Automated Unit and UI testing are performed.

 The Operations Team needs to take care of Automated scripts

that further go to the test environment.

 Testing is performed and after approval, the software is sent to

production.

 Here Continuous Integration can be referred to as Build Pipeline

and Continuous Delivery can be referred to as Release Pipeline.

Layered Architecture
There are all sorts of ways a software system might be divided, but

through experience and convention, the industry has converged on

LAYERED ARCHITECTURES, and specifically a few fairly standard

layers.

 User Interface (or Presentation Layer)

 Application Layer

 Domain Layer (or Model Layer)

 Infrastructure Layer
User Interface (or Presentation Layer)

Responsible for showing information to the user and interpreting the user's commands. The

external actor might sometimes be another computer system rather than a human user.

Application Layer Defines the jobs the software is supposed to do and directs the expressive

domain objects to work out problems. The tasks this layer is responsible for are meaningful to

the business or necessary for interaction with the application layers of other systems.

This layer is kept thin. It does not contain business rules or knowledge, but only coordinates

tasks and delegates work to collaborations of domain objects in the next layer down. It does

not have state reflecting the business situation, but it can have state that reflects the progress

of a task for the user or the program.

Domain Layer (or Model Layer)

Responsible for representing concepts of the business, information about the business

situation, and business rules. State that reflects the business situation is controlled and

used here, even though the technical details of storing it are delegated to the infrastructure.

This layer is the heart of business software.

Infrastructure Layer

Provides generic technical capabilities that support the higher layers: message sending for

the application, persistence for the domain, drawing widgets for the UI, and so on. The

infrastructure layer may also support the pattern of interactions between the four layers

through an architectural framework.

A model expressed in software
• A model is expressed in code by several patterns of model
elements:
• Value objects
• Entities
• Associations

• Services

• Packages

• Modules
• Value objects

• Value objects are attributes that describe the state of something else. They have no conceptual

identity, they describe a characteristic of another object. They are properties of other objects.

• Value objects are different than entities in how they need to be tracked. If only the value is

relevant, we are in presence of a value object. If it is also relevant what value we are referring

to, then we are in presence of an entity.

• A VALUE OBJECT can give information about an ENTITY. It should be conceptually whole.
• Entities

• Entities are objects that represent something relevant in the domain

model. They exist on their own right, they can not be swapped by another

object with the same data, they are crucial in the domain logic.

• Associations

• An association between objects can be compared at a DB level as the

connections between two tables that represent objects. It can e seen at

OOP level as an object that contains another object, or collection of

objects, as one of its properties.

• Services

• Services are objects that represent a process, as opposed to an anonymous

value or a specific thing with its own identity, data and functionality related to
that data.
• A service:Represents a process, a flow of actions on one, or several,
entities;
• Is stateless, meaning it does not hold a state that alters its behaviour. 

A good SERVICE has three characteristics.

1. The operation relates to a domain concept that is not a natural part of an

ENTITY or VALUE OBJECT.
2. The interface is defined in terms of other elements of the domain model.
3. The operation is stateless.
• Modules & Packages

• Modules should also emerge as a meaningful part of the domain

model. They group a set of functionality, a concept, and isolate

its complexity from the remaining the domain model modules and

implementations.

• Give the MODULES names that become part of the UBIQUITOUS

LANGUAGE. MODULES and their names should reflect insight into

the domain.
 Driven Design Hands‐on Models
An interesting software design technique to understand and solve

complexity is Domain Driven Design (DDD). Domain Driven Design

advocates modeling based on the reality of business as relevant to our use

cases. As it is now getting older and hype level decreasing, many of us forget

that the DDD approach really helps in understanding the problem at hand

and design software towards the common understanding of the solution.

Driven Design Hands‐on Models

When building applications, DDD talks about problems as domains and

subdomains. It describes independent steps/areas of problems as bounded

contexts, emphasizes a common language to talk about these problems, and

adds many technical concepts, like entities, value objects and aggregate root

rules to support the implementation.

Driven Design Hands‐on Models

Bounded Contexts Designed as Service Applications:

The architectural style is very similar to microservices. It is about separating

the monolithic applications into multiple stand alone service applications or

developing them separately from the beginning with the help of bounded

contexts, a DDD concept.

Driven Design Hands‐on Models
Driven Design Hands‐on Models
 Lifecycle of a domain object
• Every object has a life cycle. An object is born, it likely goes through various
states, and it eventually dies—being either archived or deleted. Of course,
many of these are simple, transient objects, created with an easy call to their
constructor, used in some computation, and then abandoned to the garbage
collector.
• There is no need to complicate such objects. But other objects have longer
lives, not all of which are spent in active memory. They have complex
interdependencies with other objects.
• They go through changes of state to which invariants apply. Managing these
objects presents challenges that can easily derail an attempt at MODEL-
DRIVEN DESIGN.
Lifecycle of a domain object
 Lifecycle of a domain object
There are three main objects that can control the life-cycle of a domain

object:

• Aggregates: Hold several objects in a root object and can control their

creation, manipulation, query and deletion;

• Factories: Create new objects with a set of data;

• Repositories: Recreate persisted objects from queried data, possibly

delegating the reconstruction of the actual object instance to a factory.

 Lifecycle of a domain object
Aggregates:

Aggregates are entities that own other entities or association objects. But

how do we define ownership? Ownership can be, for example, when in a

web-shop we have a product, lets say a t-shirt, who has variants, lets say

combinations of colours and sizes. There is one product with several

variants. It makes no sense for one of those variants to be attached to

another product, nor to exit without a product. Also, if we delete a

product, we must delete its variants.

 Lifecycle of a domain object
Rules when using aggregates:

 The root entity has global identity;

 The root entity is ultimately responsible for the objects it owns;

 The owned objects can only be reached through the aggregate root;

 The owned objects can be used by external objects, but these can not

keep references to them;

 When deleting an aggregate, all owned objects must be deleted as well.

 Lifecycle of a domain object
Factories:Factories are not a reflection of the model, but they are needed

at some point, to maintain the domain objects clear and clean of logic

irrelevant to the domain.Factories should be used when the construction

of an object or aggregate is complex.

When creation of an object, or an entire AGGREGATE, becomes

complicated or reveals too much of the internal structure, FACTORIES

provide encapsulation.
Lifecycle of a domain object
 Lifecycle of a domain object
Repositories:

We can get objects either by creation (new or reconstructed), or by trasversal of

an object that holds a reference to the object we want to get.

There are several advantages to using repositories:

 Provide a simple way to retrieve persisted objects;

 Decouple application and domain logic from the persistence technology;

 Makes testing easier by giving a way to provide a predetermined object or

collection of objects to the logic we want to test.

 Lifecycle of a domain object
A REPOSITORY doing a search for a client