Advanced Software

Engineering 1-5
Inhaltsverzeichnis
1. Slides : Domain-Driven Design (DDD).......................................................................................5
1.1 Basic Concepts of DDD.................................................................................................................5
Ubiquitous Language......................................................................................................................6
1.2 DDD Design Patterns for Model Driven Design............................................................................6
Layered Architecture......................................................................................................................7
Entity..............................................................................................................................................7
Value Object...................................................................................................................................7
Service............................................................................................................................................8
Aggregate.......................................................................................................................................8
Factory............................................................................................................................................9
Repository......................................................................................................................................9
Worksheet 01: Domain-Driven Design...........................................................................................10
Task 1: Domain-driven design basics................................................................................................10
Task 02: Relation to the development process.................................................................................12
Task 03: Domain-Driven Design Layers.............................................................................................13
Task 04: Domain-driven design example..........................................................................................14
Task 05: Entity vs. Value Object........................................................................................................15
Task 06: Service design in DDD.........................................................................................................16
Taks 07: DDD larger example............................................................................................................17
SE-Quizzes 01................................................................................................................................30
2. Slides: DDD Strategic Design..................................................................................................32
2.1 DDD Strategic Design 1...............................................................................................................32
Domain Model..............................................................................................................................32
Bounded Context..........................................................................................................................33
2.2 DDD Strategic Design 2...............................................................................................................34
Worksheet 02: Domain-Driven Design - Strategic Design...............................................................40
Task 01: Strategic Design Concepts..................................................................................................40
Task 02: Bounded Context Relations................................................................................................41
Task 03: Bounded Context Relations................................................................................................42
Task 04: Bounded Context Relations................................................................................................43
1
SE-Quizzes 02................................................................................................................................45
3. Slides: Architecture Views......................................................................................................47
3.1 Architecture Views.....................................................................................................................47
3.2 Software Architecture Views 4+1 View.................................................................................48
Scenario /Use Case View..............................................................................................................48
Logical View..................................................................................................................................48
Process View.................................................................................................................................49
Development View.......................................................................................................................50
Physical View................................................................................................................................50
Worksheet 03: Software Architecture Views..................................................................................51
Task 01: Software architecture views vs. domain-driven design......................................................51
Task 02: Studying the Zachman framework......................................................................................52
Task 03: Relating UML and the 4+1 View Model..............................................................................53
Task 04: Extracting information from use case template.................................................................54
Task 05: Use Cases and Views for an Energy Provider System (NOT ANSWERED)............................55
SE-Quizzes 03................................................................................................................................56
4. Structuring The Architecture Part 1........................................................................................58
4.1 Layers.........................................................................................................................................58
4.2 Organizing Domain Logic......................................................................................................59
4.3 Shared Repository................................................................................................................60
Worksheet 04: Patterns for Structuring the Architecture...............................................................61
Task 01: Audacity..............................................................................................................................61
Task 02: Structuring an architecture................................................................................................62
Task 03: Relation to domain-driven design......................................................................................62
Task 04: Task: Transaction Script vs. Domain Model........................................................................63
Task 05: Structuring an architecture................................................................................................68
SE-Quizzes 04................................................................................................................................70
5. Structuring the Architecture Part 2........................................................................................72
5.1 Model-View-Controller...............................................................................................................72
5.2 Pipes and Filters....................................................................................................................73
5.3 Publish/Subscribe Pattern....................................................................................................73
Worksheet 05:Patterns for Structuring the Architecture (Part 2)....................................................75
Task 01: Ruby-on-Rails Architecture.................................................................................................75
Task 02: Studying Pipes and Filters...................................................................................................76
Task 03: Studying Pipes and Filters...................................................................................................77
Task 04: Combining Layer and Pipes and Filters...............................................................................78

2
 Task 05: Studying an architecture....................................................................................................80
Task 06: Designing an MVC/Shared Repository architecture...........................................................81
SE-Quizzes 05................................................................................................................................82
6. Past Exam Questions..............................................................................................................84
7. Past Exams from Other Universities.......................................................................................92
8. Definitions (HedgeDoc)..........................................................................................................96
Value Object.....................................................................................................................................96
Entity Object.....................................................................................................................................96
Zachman-Framework........................................................................................................................96
Reference Model for Open Distributed Processing (RMODP)..........................................................96
4+1 View-Model...............................................................................................................................96
Ubiquitous Language........................................................................................................................96
A bounded context...........................................................................................................................96
Domain-drive Design........................................................................................................................96
Transaction Script.............................................................................................................................96
Applicability......................................................................................................................................97
Consequences..................................................................................................................................97
Model View Controler......................................................................................................................97
Aggregate.........................................................................................................................................97
Most Common Layers:......................................................................................................................97
9. ChatGPT Questions................................................................................................................98
4+1 View Model...............................................................................................................................98
what is Domain-Driven Design?........................................................................................................98
Domain-Driven Design (DDD) and the 4+1 View Model...................................................................99
what are the building blocks of domain driven design?...................................................................99
what is DAO?..................................................................................................................................100
Dependency injection.....................................................................................................................101
what is @qualifier?.........................................................................................................................102
what is docker image?....................................................................................................................103
layered architecture.......................................................................................................................103
What is Ubiquitous Language?.......................................................................................................104
what is Hibernate/ JPA lazy loading?..............................................................................................104
What is Shared Kernel?..................................................................................................................104
What is Partnership?......................................................................................................................105
What is the difference between Shared Kernel and Partnership?..................................................105
What is a Conformist Relation?......................................................................................................105

3
What is an Anti Corruption Layer?..................................................................................................105
How do I design a domain model?.................................................................................................106
Video: What is Software Architecture?..........................................................................................106

4
 [Link] : Domain-Driven Design (DDD)
1.1 Basic Concepts of DDD

5
Ubiquitous Language

1.2 DDD Design Patterns for Model Driven Design

6
 Layered Architecture

Entity

Value Object

7
 Service

Aggregate

Factory
8
Repository

9
Worksheet 01: Domain-Driven Design
Task 1: Domain-driven design basics
Answer the following questions about domain-driven design. Explain your answer in 2-3 sentences.

a) Explain the main differences of the use of models in domain-driven design vs. common software engineering
processes and practices such as Rationale Unified Process (RUP)?

Domain-driven design (DDD) and Rationale Unified Process (RUP) are two different approaches to software
engineering, and they have different perspectives on the use of models.

In DDD, models are used as a way of representing the domain concepts and their relationships. These models are
based on the language used by the domain experts and are used to communicate and collaborate between technical
and non-technical stakeholders. DDD places a strong emphasis on modeling, and encourages the creation of rich,
expressive models that capture the complexity of the domain.

On the other hand, RUP is a more structured and process-oriented approach to software engineering. It provides a
set of guidelines and practices for the development of software systems. In RUP, models are used primarily as a
means of documenting and communicating design decisions. RUP defines a set of models that should be created
during the development process, including use case diagrams, class diagrams, and sequence diagrams.

The main difference between the use of models in DDD and RUP is the focus on modeling. DDD places a much
stronger emphasis on modeling, with the goal of creating a rich and expressive model that reflects the domain
concepts and relationships. RUP, on the other hand, views modeling as a tool for documenting and communicating
design decisions, and defines a set of models that should be created during the development process.

Another difference is that DDD models are typically less formal and more focused on the language of the domain
experts. This can make them more accessible and easier to understand for non-technical stakeholders. In contrast,
RUP models tend to be more formal and structured, with a focus on documenting the technical details of the system.

Overall, while both approaches make use of models, the way they are used and the emphasis placed on modeling
differs significantly. DDD focuses on creating rich, expressive models that reflect the domain concepts, while RUP
uses models primarily as a tool for documenting and communicating design decisions.

b) A common view in agile methods is summarized in this quote: "Truth can only be found in one place: the code."
(Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship). How does this relate to domain-
driven design where models are used as another source of "truth"? Is there a contradiction between the two
views?

The quote "Truth can only be found in one place: the code" emphasizes the importance of focusing on the
implementation of the software system, rather than on theoretical models or documentation. This view is often
associated with Agile methodologies, which prioritize working software over comprehensive documentation.

In contrast, domain-driven design (DDD) places a strong emphasis on modeling and creating a shared
understanding of the domain concepts and relationships. Models are used to capture the domain experts'
understanding of the problem domain and to guide the development of the software system.

While there may appear to be a contradiction between the two views, they are not necessarily mutually exclusive. In
fact, they can be complementary. The quote emphasizes the importance of focusing on the implementation of the
software system, but it does not imply that models or documentation are not necessary. Similarly, DDD
acknowledges the importance of working software but emphasizes the importance of creating a shared
understanding of the problem domain through modeling.

In DDD, models are used to guide the implementation of the software system, and they serve as a source of truth for
the development team. However, the models are not the only source of truth. The implementation of the software

10
system itself is also a source of truth, and the development team must ensure that the implementation is consistent
with the models.

Therefore, while the quote emphasizes the importance of the implementation of the software system, it does not
contradict the use of models in DDD. Both views recognize the importance of creating a shared understanding of the
problem domain, and they can be used together to guide the development of the software system.

c) Why and how can the ubiquitous language concept and DDD improve the quality of the software that is
produced in a SW development project?

The ubiquitous language concept and domain-driven design (DDD) can improve the quality of the software produced
in a software development project in several ways:

Shared Understanding: By creating a ubiquitous language that is used by all stakeholders involved in the project, a
shared understanding of the domain concepts and requirements can be established. This helps to ensure that
everyone is working towards the same goals, reducing the risk of miscommunication and misunderstandings.

Focus on Business Value: DDD emphasizes understanding the business domain and focusing on delivering business
value. By aligning the software system with the business domain, DDD can help to ensure that the software system
meets the needs of the business.

Improved Design: By creating a rich and expressive model of the domain, DDD can help to guide the design of the
software system. This can lead to a more modular, maintainable, and extensible design that is better suited to the
needs of the business.

Reduced Complexity: DDD helps to reduce the complexity of the software system by breaking it down into smaller,
more manageable components that are easier to understand and reason about. By using a common language and
creating a shared understanding, the development team can work together to simplify the system and reduce its
overall complexity.

Increased Testability: DDD can improve the testability of the software system by providing a clear understanding of
the domain concepts and relationships. This can help to guide the creation of test cases that cover all the important
scenarios and ensure that the software system is functioning as intended.

Overall, the ubiquitous language concept and DDD can help to improve the quality of the software produced in a
software development project by creating a shared understanding of the domain, focusing on delivering business
value, guiding the design of the software system, reducing complexity, and increasing testability. By using these
concepts and practices, development teams can create software systems that are better suited to the needs of the
business and that are more maintainable, extensible, and reliable.

d) When and how long does a DDD model need to be maintained and evolved?

A domain-driven design (DDD) model needs to be maintained and evolved throughout the lifecycle of the software
system. The model is not a one-time artifact that is created at the beginning of the project and then forgotten.
Rather, the model is a living artifact that should be continuously updated and refined as the understanding of the
domain and the requirements evolves.

The need for maintaining and evolving the DDD model will depend on several factors, such as the complexity of the
domain, the size of the software system, and the rate of change in the business domain. In general, the DDD model
should be updated whenever there is a significant change in the domain, such as a new business requirement, a
change in the market, or a change in the organization's strategy.

The amount of time needed to maintain and evolve the DDD model will also depend on these factors. In some cases,
the model may need to be updated frequently, while in other cases, it may need to be updated less frequently.
However, it is important to note that the DDD model should always be considered as a critical artifact that should be
maintained and evolved to reflect the current understanding of the domain.

11
It is also important to note that the maintenance and evolution of the DDD model should not be left to a single
person or team. Rather, it should be a collaborative effort involving all stakeholders, including domain experts,
business analysts, developers, and testers. This ensures that the model remains relevant and accurate and that it
continues to reflect the shared understanding of the domain.

e) Which/how many developers in a DDD-based software development project need to learn about modelling and
DDD concepts?

In a domain-driven design (DDD)-based software development project, all developers involved in the project should
learn about modelling and DDD concepts. This includes not only the developers responsible for the core business
logic but also the developers responsible for the user interface, infrastructure, and integration.

The reason for this is that DDD is a collaborative and interdisciplinary approach that requires a shared understanding
of the domain and its concepts. The developers responsible for the user interface, infrastructure, and integration
need to understand the domain concepts and how they relate to their work. For example, the developers
responsible for the user interface need to understand the user interactions and the language used by the end-users,
while the developers responsible for the infrastructure need to understand the technical requirements and
constraints of the system.

By having all developers learn about modelling and DDD concepts, the team can work together to create a shared
understanding of the domain, which can help to ensure that the software system is well-aligned with the business
requirements and meets the needs of the end-users.

Furthermore, the team should also involve other stakeholders, such as business analysts and domain experts, to
ensure that everyone has a clear understanding of the domain concepts and requirements. This can help to facilitate
communication and collaboration among all stakeholders, leading to a more effective and successful software
development project.

Task 02: Relation to the development process

Domain-driven design (DDD) is an approach to software development that emphasizes understanding and modeling
the domain of the problem being solved, and using that model to guide the design and implementation of the
software system. DDD is not a development process in itself, but rather a set of principles and practices that can be
applied within different development processes, such as Rational Unified Process (RUP) or agile methods like Scrum.

In RUP, DDD can be used to guide the analysis and design phases of the process, by emphasizing the importance of
understanding the business domain and using that understanding to guide the creation of the system architecture
and design. RUP also provides guidelines for modeling the domain, which can be used in conjunction with DDD
principles and practices.

In Scrum, DDD can be used to guide the development of the product backlog, by emphasizing the importance of
understanding the domain and using that understanding to identify and prioritize user stories. DDD can also be used
to guide the design and implementation of the system, by emphasizing the importance of using the ubiquitous
language and creating a domain model that reflects the shared understanding of the domain.

Overall, DDD can be used in conjunction with both RUP and agile methods like Scrum to provide a common language
and understanding of the problem domain, which can help to ensure that the software system meets the needs of
the business and end-users. However, it is important to note that DDD is not a one-size-fits-all approach, and the
application of DDD principles and practices should be adapted to the specific needs and context of the project.

12
Task 03: Domain-Driven Design Layers

How does this architecture map to the domain-driven design layers?

Is this a good layering according to domain-driven design?

 Presentation corresponds to the User Interface layer

 Application corresponds to the Application layer because it does not access data access logic and it is
responsible for navigation between UIs
 Service corresponds to the Domain layer as it contains service objects which encapsulate behavior from
business objects

I would say that Data Access (supporting library) and Persistence (implements persistence of business objects)
corresponds to the Infrastructure layer because it seems that they provide support for other layers and
communication between them.

I would say that this is quite layering and that it corresponds to the domain-driven design rules.

I would say that this is quite layering and that it corresponds to the domain-driven design rules. It helps to introduce

literal mapping of the domain model to code + supports to fulfill the separation of concerns, isolating the domain
layer.

13
Domain-driven Design Layers

User Interface (presentation layers): all what users can see

Application Layer (logid what do you do)

Domain Layer

Infrastructure Layer (e.g. databases)

The domain layer:

is responsible for the concepts of business domain, information about the business use case and the business rules.
Domain objects encapsulates the state and behaviour of business entities. Examples of business entities in a loan
processing application are Mortgage, Property, and Borrower.

can also manage the state (session) of a business use case if the use case spans multiple user requests (e.g. loan
registration process which consists of multiple steps: user entering the loan details, system returning the products
and rates based on the loan parameters, user selecting a specific product/rate combination, and finally the system
looking at the loan for that rate)

contains service objects that only have a defined operational behaviour which is not part pf any domain model.
Services encapsulates behaviour of the business domain that doesn’t fit in the domain objects themselves.

is the heart of the business application and should be well isolated from the other layers of the application. Also, it
should not be dependent on the application frameworks used in the other layers (JSP/JSF, Struts, EJB, Hibernate,
XMLBeans and so on).

Task 04: Domain-driven design example

14
 1) If we delete a BacklogItem instance what are the consequences for the instances of the other 5 classes in
the model?
 Value objects: ProductID, ReleaseID and SprintID will be deleted. Entity “Task” and value object
“EstimationLogEntry” will remain. Task must be deleted. Everything which is aggregated to the BacklogItem
should be deleted.
 EstimationLogEntry should be deleted. Value objects should be deleted.
 BacklogItem implements Aggregate concept (cf. DomDri/15). Therefore the valueObjects that are only
connected to the BacklogItem are deleted.
 The task as entity continues to exist, as do linked EstimationLogEntries.
2) What are the consequences for Products, Releases, and Sprints? What is the relation of those concepts to
the classes in the model? If we would model Products, Releases, and Sprints, would they be entities or
value objects?

Products, Releases and Sprints are not deleted, because they have their own life cycle. The Id value objects are
class variables of them. If we model Product, Release and Sprint they would be entities.

3) Could we link Products, Releases, and Sprints in the same way to BacklogItem as ProductID, ReleaseID,
and SprintID are linked?
 No, because Product, Release and Sprint have their own life cycle and they are not aggregated to the
BacklogItem.
 No, because products, releases and sprints exist independently of individual backlog items and would
therefore be entities, not ValueObjects.

Task 05: Entity vs. Value Object

Model the following situation as a UML class diagram: “A flight has a unique flight number, a departure time, and
an arrival date. Airports have a unique code like “VIE” for Vienna. Each flight has a departure and arrival airport.
One plane operates a number of flights. A plane has a unique ID and a type, and it has a number of seats each
with a seat number. A passenger on a flight has a first and a last name. A number of passengers are booked on a
flight. Per booked flight, passengers book a seat and provide a meal preference (a simple text). A passenger need
1 ticket for a flight, containing an outbound flight and a return flight. A ticket has a price and a status which is
either pending of purchased.”

Two important concepts in domain-driven design are Entities and Value Objects. Identify all Entities and Value
Objects in the following domain model and explain for each element why you identified it as Entity or Value
Object. Mark each Entity with an “E” and each Value Object with a “V”. Also make aggregate roots with an
additional “AR”. Discuss why. Also discuss if there is more than one option.

15
Flight is AR because it represents a collection of objects that are band together by a root entity.

• Value Objects contain attributes, but have no conceptual identity.

• Entities are objects that are not defined by its attributes, but rather by a thread of continuity and its identity

Task 06: Service design in DDD

Which of the following statements about good service design in domain-driven design are correct?

a) The service operation relates to a domain concept that is not a natural part of an entity or value object.
b) The service operations relate to a domain concept and must be a natural part of an entity or value object.
c) The service interface is defined in terms of other elements of the domain model.
d) The service interface contains no other elements of the domain model.
e) The service operation maintains an internal state that affects its own behavior (i.e. it is stateful).
f) The service operation does not maintain an internal state that affects its own behavior (i.e. it is stateless).
g) The service operation can either be stateful or stateless.

Correct + Explanation:

16
a) Service operations in domain-driven design should be designed to represent domain concepts that are not
naturally part of entities or value objects. This means that they should represent behaviors or actions that don't fit
well within the context of a particular entity or value object.

c) The service interface should be defined in terms of other elements of the domain model, such as entities or value
objects. This helps to ensure that the service is well-aligned with the domain model and that it provides a clear and
consistent representation of the domain concepts.

f) Service operations should be designed to be stateless, meaning that they do not maintain an internal state that
affects their behavior. This makes it easier to reason about the behavior of the service, and it can also make the
service more scalable and resilient.

Statements b, d, e, and g are incorrect or incomplete:

b) This statement is incorrect because service operations are not required to be a natural part of an entity or value
object. Rather, they should be designed to represent domain concepts that don't fit well within the context of a
particular entity or value object.

d) This statement is incomplete because the service interface should be defined in terms of other elements of the
domain model, as stated in statement c.

e) This statement is incomplete because it doesn't provide enough context. Service operations can maintain an
internal state, but they should be designed to minimize the impact of that state on their behavior.

g) This statement is incomplete because it doesn't provide enough context. Service operations can be stateful or
stateless, but they should be designed to minimize the impact of state on their behavior.

Taks 07: DDD larger example

Study the domain-driven design example at: [Link]

A company provides IT Body Leasing. They have some Employees, and also a lot of Freelancers as Subcontractors.
Currently, they use Excel sheets to manage their Customers, Freelancers, Timesheets and so on. The Excel solution
does not scale well. It is not multi-user ready and also does not provide security and audit logs. So they decided to
build a new web based solution. Here are the core requirements:

 A searchable catalog of Freelancer must be provided

 The new solution must allow to store the different Communication Channels available to contact a
Freelancer
 A searchable catalog of Projects must be provided
 A searchable catalog of Customers must be provided
 The Timesheets for the Freelancers under contract must be maintained

Based on these requirements the development team decided to model everything using UML to get a big picture of
the new solution. Now let’s see what they did.

17
Before:

This is pretty straight forward. There are Customers, Freelancers, Projects and Timesheets. There is also a kind of
user management to support role based security. But wait, something is wrong here. There are some well hidden
design flaws. Can you see them? Here they are:

 It is a very big object graph. If they do not use Hibernate/ JPA lazy loading here, it will pretty sure run out of
memory under heavy load
 Why is the association between User and Role bi-directional?`
 The ContactType has some boolean flags to show what type is it, email, phone, mobile
 The Freelancer class holds a list of Projects. This also means that Projects cannot be added without
modifying the Freelancer object. This can cause transaction failure under heavy load, as possibly multiple
users are adding Projects for the same Customer.
 What does ContactInformation mean? The requirements stated “Communication Channel”. Is it the same?

18
The whole model seems to be more a kind of Entiy-Relationship-Diagram instead of a software model. Also, were is
the business logic? The team wanted to create some Business-Services around the model to store and retrieve data,
the Entities are just POJOs managed by JPA.

The hole solution is a big code smell, an anemic domain model. The team does this recognize, too. But what can be
the solution? Well, a senior team member suggested to use Domain-driven Design principles to model the solution.
Ok, now let’s see how DDD can improve the design.

The DDD way

Before we start in deep to look at Domain-driven Design, we should talk a little about the principles behind DDD.

One principle behind DDD is to bridge the gap between domain experts and developers by using the same language
to create the same understanding. Another principle is to reduce complexity by applying object oriented design and
design patters to avoid reinventing the wheel.

But what is a Domain? A Domain is a “sphere of knowledge”, for instance the business the company runs. A Domain
is also called a “problem space”, so the problem for which we have to design a solution.

Ok, let’s look at the requirements. We could think that there is a “Body Leasing” Domain, and that is completely
right. But if we look deeper into the Domain, we see something that is called “Subdomain”. The following
Subdomains might be possible:

 Identity and Access Management Subdomain

 Freelancer Management Subdomain
 Customer Management Subdomain
 Project Management Subdomain

Ahh! We can split the big problem into smaller ones. This can help us to design a better solution.

The separated Domain can easily be visualized. In DDD terms this is called a Context Map, and it is the starting point
for any further modeling.

Now we need to align the Subdomain aka problem space to our solution design, we need to form a solution space. A
solution space in DDD lingo is also called a Bounded Context, and it is the best to align one problem
space/Subdomain with one solution space/Bounded Context.

19
Building blocks
The building blocks of Domain-driven Design are split into tactical and strategical patterns. I wrote an Article about
DDD building blocks so if you want to dive deeper please visit this article.

Please note that the following architecture patterns and class diagrams are not technology dependent. This solution
can be implemented using Java SE/EE, C# or even JavaScript. It does not matter, we can archive the same benefit
with every target technology.

Okay, what happened here? There are now Bounded Contexts for every identified Subdomain. The Bounded
Contexts are isolated, they know nothing of each other. They are only glued together by a set of common types, like
UserId, ProjectId and CustomerId. In DDD this set of common types is called a “Shared Kernel”. We can also see what
is part of the "Core domain" and what is not. If a bounded context is part of the problem we are trying to solve and
cannot be replaced by another system, it is part of the "Core domain". If it can be replaced by another system, it is a
"Generic Subdomain". The "Identity and access management" context is a "Generic Subdomain", as it could be
replaced by an existing IAM solution, such as Active Directory or something else.

We applied a set of tactical and strategical patterns to the model. These patterns help us to build a better model,
improve fault tolerance and also to increase maintainability.

Within each Bounded Context there are Aggregates and Value Objects. Aggregates are object hierarchies, but only
the root of the hierarchy is accessible from outside of the Aggregate. Aggregates take care of business invariants.
Every access to the object tree must go thru the Aggregate and not over one element within. This greatly increases
encapsulation.

20
Aggregates and Entites are things with an unique id in our model. Value Objects are not things, they are values or
measures, like a UserId. Value Objects are designed to be immutable, they cannot change their state. Every state
changing method returns a new instance of the value Object. This helps us to eliminate unwanted side effects.

21
22
23
24
25
26
27
Explain what Bounded Contexts are and how they are used to improve the initial design.

Bounded Context is a central pattern in Domain-Driven Design. It is the focus of DDD’s strategic design section which
is all about dealing with large models and teams. DDD deals with large models by dividing them into different
Bounded Contexts and being explicit about their interrelationships.

Bounded Context is a solution space which is used to align sub-domain aka problem space to the solution design.
This is used to make complex models simple and to divide complete picture into smaller isolated pieces which know
nothing of each other, but which gives better understandability of the whole domain. They are glued together by a
set of common types/value objects. Bounded Context increases encapsulation because each Bounded Context has
Aggregates and Value Objects and every access to the object three from outside of the Aggregation must go through
the Aggregate.

Bounded Context vs Module:

A Bounded Context is not a Module. A Bounded Context provides the logical frame inside of which the model
evolves. Modules are used to organize the elements of a model, so Bounded Context encompasses the Module

Why does the improved aggregate-based design for Freelancer provide improved encapsulation and
responsibilities?

Because the aggregation root has only method which returns imitable instance of Address from the Freelancer. We
can apply role based security to this method. By just returning immutable objects out of the Aggregate we can make
sure that nothing can change the internal state of the Aggregate except the Aggregate itself. Within each Bounded
Context there are Aggregates and Value Objects. Aggregates are object hierarchies, but only the root of the
hierarchy is accessible from outside of the Aggregate. Aggregates take care of business invariants. Every access to
the object tree must go thru the Aggregate and not over one element within. This greatly Increases encapsulation.

28
Discuss for each of the aggregate roots in the domain-driven design: Are they entities or value objects? Which
concept of identity do they have? Which concept of identity do the members of the aggregates have? What
happens to the aggregate members if we delete to aggregate roots?

User - E

Role - V

Freelancer - E

TimeSheet - V

Project - E?

Customer - E

If we delete aggregate roots, aggregate members will be deleted.

Why is the HibernateFreelancerRepository at the Infrastructure layer and the FreelancerRepository at the domain
layer? Could we move both to the same layer? How would the resulting design look like?

Because Infrastructure layer provides the technology dependent artifacts which supports other layers. We cannot
move both on the same layer. This makes it easy to change the repository technology to JPA, NoSQL

The Domain Layer contains the infrastructure independent domain logic as we modeled before in this example. The
Infrastructure Layer provides the technology dependent artifacts, like the Hibernate based FreelancerRepository
implementation. HibernateFreelancerRepository is used for connection with DB, all infrastructures are in
Infrastructure layer. FreelancerRepository is in Domain layer, because it should be used for business logic.

The resulting model contains many details related to user interface and persistence. This does not look like an
analysis model for domain experts. Would it be better to get rid of them? Or have two models, an analysis and a
design model?

Maybe it has sense to have both, because of richness of information of the domain.

Discuss for FreelancerApplicationService why it fulfills the characteristics of good service design identified in Task
6 or why not.

The FreelancerApplicationService is not a natural part of an entity Freelancer. It just loads it form the
FreelancerRepository.

The service interface is defined in terms of other elements of the domain model.???

It satisfies the stateless requirement, too.

The client sends a command to the ApplicationService. The ApplicationService translates the command to a Domain
Model use case invocation. So the FreelancerApplicationService will load the Freelancer Aggregate from the

FreelancerRepository and invoke the moveTo() operation on the Freelancer Aggregate. The
FreelancerApplicationService forms also the transaction boundary. Every invocation results in a new transaction.
Role based security can also be implemented using the FreelancerApplicationService. It is always a good choice to

keep transaction control out of the domain model. Transaction control is more a technical issue than a business
thing, so it should not be implemented in the domain model.

29
SE-Quizzes 01
Based on the diagram above, select the statements
which are correct:

a) The ClinicalTreatment can be seen as an Entity

because the cost attribute has a thread of continuity and identity

b) The Dog is an Entity because it encapsulates the state of the Critical Treatment cia the Layers Pattern

c) The Clinical Treatment defines no concent of identity for the Dog. Therefore, the Dog is a Value Object.

d) The Clinical Treatment provides additional information on the Dog. Therefore, it is a value Object.

Answer: d)

Based on the diagram above, select the statements which are correct:

a) The RoomType gives further information on the Hotel. But

the RoomType itself cannot be classified according to an
identity concept. For this reason, the RoomType is a Value
Object for the Hotel.

b) The RoomServiceOffer further complements the Hotel

with attributes and information.

c) The RoomServiceOffer provides a repository to the Hotel.

Therefore, this is an example of the Repository Pattern.

d) The Hotel can be seen as an Entity because its

companyRegistrationNumber conveys a concept of identity.

Answer: a), b), d) (correct)

Consider the following Java code, and select which of the following statements are valid.

a) In order to support comparing Address objects, it makes sense to realize before

equals() and hashCode() methods such as the ones below:

b) When comparing one Address object called address1 of a Customer to another

Address object called address2, we can simply use (address1 == address2).

c) To denote the immutability of the Value Objects in this example, we can make
them final, make all their fields final, and copy all mutable state during construction
and retrieval, for example using Java’s method clone().

d) In a Domain Model, Customer would be modelled as an Entity and all other classes would be modelled as Value
Objects.

30
e) Address is a Value Object. As it contains a number of properties, it makes sense to model it as a Value Object.
FirstName and LastName are modelled just like Value Objects, but as they are just Strings, they should actually be
modelled as Strings in Customer, not as objects in their own right.

Answer: a), c), d) (correct)

Answer c more information:

In object-oriented programming, immutability refers to the characteristic of an object whose state cannot be
modified once it is created. It means that once the object is created, all of its fields and values remain the same
throughout the object's lifetime.

In the context, it means that the Value Objects should be designed in a way that they cannot be changed after
creation. One way to achieve this is to make the objects "final", which prevents them from being subclassed or
changed in any way. Additionally, all the fields of the Value Objects should be made "final" to ensure that their
values cannot be changed once they are set.

Copying all mutable state during construction and retrieval means that whenever the object is created or retrieved,
all of its fields' values are copied to ensure that the object's state remains immutable. This can be done using the
"clone()" method in Java, which creates a copy of the object's state that can be safely returned or used without
altering the original object's state.

Based on the model, select the statements which are correct:

a. The above model (maybe with a number of

extensions) can be the foundation for developing a
common project language for a project team.

b. Information on the salary is made explicit by the

rule mentioned in the note.

c. When we look at the above model, we know

everything about the underlying domain.

d. As a model for domain-driven design, this model is

not elaborated enough: Detailed knowledge of fields
and operations to be used in the implementation are missing.

Answers: a) , b) (correct)

Based on the diagram, select the statements which are correct:

a. The teacherId and the contractId refer to

identity concepts. For this reason, the identity
stays with the Teacher and the Contract. They
are thus Entities.

b. The Course Description defines additional

attributes of the Course, which are not directly
related to an identity concept. So, the Course
Description is an Entity.

c. The Course Description defines additional attributes of the Course, which are not directly related to an identity
concept. So, the Course Description is a Value Object.

d. The Contract is directly dependent on the Teacher. Therefore, it does not have an identity concept. It is a Value
Object. Answers: a) , c) (correct)

31
 [Link]: DDD Strategic
Design
2.1 DDD Strategic Design 1

Domain Model

32
Bounded Context

33
2.2 DDD Strategic Design 2

34
35
36
37
38
39
Worksheet 02: Domain-Driven Design - Strategic Design
Task 01: Strategic Design Concepts
a) Explain in your own words what is the relation between Bounded Context, Problem Domain, Solution Space,
Subdomain, and Problem Space in DDD.

In Domain-Driven Design (DDD), a Bounded Context is a specific area or boundary in a software system where a
common language and set of terms are used to describe the relevant concepts and behaviors.

The Problem Domain refers to the area of knowledge or expertise that a software system is intended to address,
such as finance, healthcare, or logistics. It includes the relevant concepts, rules, and constraints that govern the
behavior of the system.

The Solution Space, on the other hand, refers to the design and implementation of the software system itself,
including the software architecture, components, and code.

A Subdomain is a smaller area within a larger Problem Domain that is still complex enough to require its own
Bounded Context. In other words, it is a specific subset of the Problem Domain that can be addressed independently
and may have its own unique set of concepts and behaviors.

Finally, the Problem Space refers to the overall context and environment in which the software system operates,
including the stakeholders, users, competitors, and other factors that can influence the design and behavior of the
system.

In summary, these concepts in DDD are all interrelated and help to define and delimit the boundaries and context of
a software system. The Bounded Context provides a common language and terms within the Solution Space that are
specific to the relevant Subdomains of the larger Problem Domain. Understanding the overall Problem Space is also
important for ensuring that the software system meets the needs and expectations of its stakeholders and users.

b) Explain in your own words what is the relation of a Bounded Context to the system architecture and the
Ubiquitous Language.

In Domain-Driven Design (DDD), a Bounded Context is a specific area or boundary within a software system where a
common language and set of terms are used to describe the relevant concepts and behaviors. A Bounded Context
represents a clear separation of concerns within the system architecture, as each Bounded Context is responsible
for a specific area of functionality.

The Ubiquitous Language, which is a key concept in DDD, refers to a common language used by all stakeholders
within a software project, including developers, domain experts, and business users. The language is used to
describe the concepts, behaviors, and rules of the system in a way that is easily understandable and consistent
across the entire project.

The relationship between Bounded Context and Ubiquitous Language is that each Bounded Context has its own set
of terms and language that are specific to the area of functionality it covers. The language used within a Bounded
Context is a subset of the overall Ubiquitous Language and is tailored to the specific needs and requirements of that
context.

The use of a Bounded Context helps to ensure that the Ubiquitous Language is clear and consistent within each
context, as each Bounded Context has a specific and well-defined purpose within the overall system architecture.
This allows developers and domain experts to work closely together within each Bounded Context, using a language
and terminology that is specific to that context.

40
Overall, the relationship between Bounded Context and Ubiquitous Language is critical to the success of a DDD
project, as it helps to ensure that the software system is designed and developed in a way that is clear, consistent,
and easily understandable by all stakeholders involved.

Task 02: Bounded Context Relations

Consider a system in which Customers are needed in a Billing and a Marketing Bounded Context. Would it make
sense to use the same Customer abstraction is both cases? Provide at least one possible property and one possible
operation of Customer in the Billing Context and also at least one possible property and one possible operation of
Customer in the Marketing Context. Draw a Context Map, decide for the integration pattern(s) used for the
Bounded Context relations, and explain why you selected this/those pattern(s).

No, It would be better to use 2 abstractions

BillingContext:

Name, Address, Company, last

convos, …

amountOfOrders()

sendInvoice()

getPayments()

MarketingContext:

Name, alter, TargetGroup,…

SendCatalog()

In this context map, both the Billing and Marketing Contexts have a one-to-one relationship with the Customer
abstraction.

For the integration pattern, I would recommend using the Anti-Corruption Layer pattern. This pattern is used to
isolate a Bounded Context from other contexts with different models and languages. In this case, the Anti-Corruption
Layer would be responsible for translating between the Customer abstraction used in the Billing Context and the
Customer abstraction used in the Marketing Context, ensuring that each context can use the Customer abstraction
that is best suited for its specific needs. This approach helps to maintain a clear separation of concerns between the
two contexts while also allowing for seamless integration when necessary.

41
Task 03: Bounded Context Relations
Consider you want to implement a Booking system for delivering small goods in cities like Vienna. You want to
base your system on a legacy system for managing work orders which already exists and works well, but does not
conform to the design and coding standards defined for your new system. You need to provide route planning for
the vehicles that deliver the goods. For this you plan to use an existing Scheduling Web Service and an Online Map
Web Services, both provided by third parties that you can use based on a monthly subscription fee via a public
API. You need to provide APIs to enable companies handling the goods delivery to connect their software systems
to your booking system. Draw a Context Map for this situation. Explain why you have chosen the Integration
Patterns used in this Context Map.

LegacySystem Bounded Context BookingSystemBoundedContext

RoutePlanningAPI
WorkOrderBoundedC
ontext

External API for Goods

Delivery Integration

Third Party Scheduling & Online Map Services

Bounded Context

Scheduling Web Service

Online Map Web Service

In this Context Map, we have three Bounded Contexts - the Legacy System Bounded Context, the Booking System
Bounded Context, and the Third Party Scheduling & Online Map Services Bounded Context. The arrows between the
Bounded Contexts represent the Integration Patterns used.

The Booking System Bounded Context uses the Route Planning API provided by the Third Party Scheduling & Online
Map Services Bounded Context to plan routes for the goods delivery vehicles.
The Booking System Bounded Context also provides an External API for Goods Delivery Integration which allows
companies handling the goods delivery to connect their software systems to the Booking System.
The Legacy System Bounded Context is separate from the Booking System Bounded Context and does not directly
integrate with it.
The Third Party Scheduling & Online Map Services Bounded Context provides the Scheduling Web Service and Online
Map Web Service via public APIs that can be accessed by the Booking System Bounded Context.
The Integration Patterns used in this context map are External API and Separate Ways. The Booking System Bounded
Context exposes an External API for Goods Delivery Integration, allowing companies to connect their software
systems to the Booking System. The Legacy System Bounded Context is separate from the Booking System Bounded
Context and does not directly integrate with it, thus following the Separate Ways pattern. The Booking System
Bounded Context also uses a third-party Scheduling & Online Map Services Bounded Context, which provides public
APIs that can be accessed by the Booking System Bounded Context, following the External API pattern.
42
The Booking System Bounded Context has a Consumer relationship with the Third Party Scheduling & Online Map
Services Bounded Context, as it consumes the services provided by the latter. The Booking System Bounded Context
also has a Provider relationship with the Goods Delivery Integration Bounded Context, as it provides an External API
that can be consumed by the latter. The Legacy System Bounded Context is not directly integrated with the Booking
System Bounded Context, so they are not in any direct relationship.

Task 04: Bounded Context Relations

Consider the software system of a Golf Club needs to be designed and then implemented by your company. Your
company is a software development firm and has the capacity to let 1 mid-size or 2-3 small teams work on the
project. In the software system to be developed, the Golf Club needs member management and payment
handling for its members. Guests can play in the Golf Club for various kinds of fees, e.g. a daily fee, a weekend fee,
etc. Members can book times on Golf course to play, and take along guests (who have paid the fee).

a) Your software design team suggests to model the situation with a Shared Kernel between Bounded Contexts. If
you think this makes sense, model the situation by sketching the class design and the Context Map, else argue
why it makes no sense.
In this case, it might make sense to use a Shared Kernel between the Member Management and Payment Handling
Bounded Contexts, as they are closely related and share some common concepts such as Members and Payments.
Here is a sketch of the class design and the Context Map:

Class Design:

 Member

 Payment

 Booking

 Guest

Context Map: Golf Club Bounded Context

 Member Management Bounded Context (Shared Kernel)

 Payment Handling Bounded Context (Shared Kernel)

b) Your software design team suggests to model the situation with a Partnership relation between Bounded
Contexts. If you think this makes sense, model the situation by sketching the class design and the Context Map,
else argue why it makes no sense.
In this case, it might make sense to use a Partnership between the Member Management and Payment Handling
Bounded Contexts, as they are independent and have different responsibilities. Here is a sketch of the class design
and the Context Map:

Class Design:

Member

Payment

Booking

Guest

Context Map:

Golf Club Bounded Context

Member Management Bounded Context (Partner)

Payment Handling Bounded Context (Partner)

43
c) Your software design team suggests to model the situation with a Conformist relation between Bounded
Contexts. If you think this makes sense, model the situation by sketching the class design and the Context Map,
else argue why it makes no sense.

In this case, it might not make sense to use a Conformist between the Member Management and Payment Handling
Bounded Contexts, as they have different responsibilities and do not share a common domain

d) Your software design team suggests to model the situation with an Anti-Corruption Layer between Bounded
Contexts. If you think this makes sense, model the situation by sketching the class design and the Context Map,
else argue why it makes no sense.

The anti-Corruption Layer is not needed here, as there is no legacy code or system used.

e) Your software design team suggests to model the situation with a single Bounded Context. If you think this
makes sense, model the situation by sketching the class design and the Context Map, else argue why it makes no
sense.

In this case, it might make sense to use a single Bounded Context to handle all the functionalities of the Golf Club
system, as it is a relatively small system and does not have complex domain models. Here is a sketch of the class
design and the Context Map:

Class Design:

Member

Payment

Booking

Guest

Context Map:

Golf Club Bounded Context

44
SE-Quizzes 02
Consider the following Java code, and select which of the following statements are valid.

[Link] placeOrder method is responsible for processing

customer orders. After an order is processed, the event is
published to the EventBus. This represents a Bounded
Context relation to the Shipping Bounded Context. The
code could realize an Anti-Corruption Layer
implementation.
b. The placeOrder method is responsible for processing
customer orders. After an order is processed, the event is
published to the EventBus. This represents a Bounded
Context relation to the Shipping Bounded Context. The
code could realize a Shared Kernel relation, where the
Shared Kernel is not defined in another context or module
but via the shared events.
c. The placeOrder method is responsible for processing
customer orders. After an order is processed, the event is
published to the EventBus. This method shall run in one
transaction context. That is, methods using events of the
EVENT_ORDER_READY_FOR_SHIPMENT event type shall be
implemented within the same Bounded Context as the
placeOrder method.
d. The example defines code which could implement the
following Domain Model: All classes are domain model
elements placed in a Bounded Context called Order
Context. OrderItem and CustomerOrder are Entities, and
CustomerOrder is an Aggregate Root.
Answers :B, D
Consider a system of a Public Library needs to support book search and borrowing of books. It is decided to model
this with two Bounded Contexts, Book Search and Book Borrowing. Book is modeled as an Entity that appears in
both Bounded Contexts: Book Search and Book Borrowing. Which of the following statements are valid?
a) The book in the Bounded Contexts Book Search is a set of data items such as author and title. The book in Book
Borrowing is a concrete exemplar of a book. Thus, the two book concepts are substantially different. Still one
describes the other one.
b) The fact that book needs to be modelled twice implies that transactional boundaries are not well set in this
example. It should be considered to redesign the model in order to join the two Bounded Contexts into one.
c) As some book data is needed by both Bounded Contexts alike, a valid design is to introduce yet another Bounded
Context called Book Masterdata which provides the shared book data as an Open Host Service.
d) The relationship between the Bounded Contexts Book Search and Book Borrowing need to ensure that Book is
consistent in both contexts. For example, a Partnership or Shared Kernel relation would support this.
Answer: a, c, d
Further explanation:
a. As some book data is needed by both Bounded Contexts alike, a valid design is to introduce yet another Bounded
Context called Book Masterdata which provides the shared book data as an Open Host Service. This is a valid
approach to provide shared book data between two Bounded Contexts.

45
b. The fact that book needs to be modelled twice does not necessarily imply that transactional boundaries are not
well set. It may be a valid design decision to model the same entity in multiple contexts. For example, the book data
needed for book search may be different from the book data needed for book borrowing, hence two separate
contexts.
c. The relationship between the Bounded Contexts Book Search and Book Borrowing needs to ensure that Book is
consistent in both contexts. For example, a Partnership or Shared Kernel relation would support this. This is a valid
approach to ensure consistency between the two contexts.
d. The book in the Bounded Contexts Book Search is not just a set of data items such as author and title. It is also an
entity that can be borrowed. The book in Book Borrowing is also an entity that can be borrowed. The two concepts
are not substantially different. The book in Book Search represents a book that can be borrowed while the book in
Book Borrowing represents an actual instance of a borrowed book.
Consider the Context Map example. Which of the
following statements are valid?
a. The Customer Management Context is
responsible for managing all the data of the
insurance company’s customers. Such a central
Bounded Context should not implement an Anti-
Corruption Layer to another context. Instead the
other context should be redesigned to conform or
partner with the Customer Management Context.
b. The Context Map indicates that the risk management context works in a close relationship with the Policy
Management Context. This makes sense as it calculates risks which influence contracts and policies, which are
closely related to Policy Management.
c. The relations of Printing Context indicate it might be an external system which is accessed by an API by many
internal contexts.
d. The debt collection context is responsible for the financial income of the insurance company (the debts) which
depend on the corresponding contracts and policies. Thus, a Shared Kernel is a sub-optimal choice for this relation. A
Conformist relation would represent the dependencies between the two Bounded Contexts better.
Answer: b, c
Decide whether the following related statements are valid (true) from the points of view presented in the lecture
materials.
a. Code belonging to a Bounded Context should implement a single sub-domain, and ideally have no clue about
other sub-domains other than the interfaces with which it interacts.
b. A Bounded Context should fall under the purview of exactly one team.
c. A Bounded Context defines a team organization boundary. It does not define its own Ubiquitous Language or its
own architecture.
d. A Bounded Context represents a single sub-domain, but that does not mean it has a specific responsibility or that
that responsibility is enforced with explicit boundaries.
e. The following definition of domain is in-line with the concepts of Strategic DDD: Domain is the reality we inhabit:
its entities, their behavior, and laws they obey. It existed before us and will exist after us, in one form or another.
Answer: a, b, e

46
 [Link]: Architecture
Views
3.1 Architecture Views

47
3.2 Software Architecture
Views 4+1 View

Scenario /Use Case

View

48
Logical View

49
Process View

50
Development View

Physical View

51
Worksheet 03: Software Architecture Views
Task 01: Software architecture views vs. domain-driven design
How do software architecture view concepts and domain-driven design relate? A concept contained in some
software architecture view concepts is refinement of models in multiple levels (“zoom factor”). How does this
concept relate to domain-driven design?

Software architecture views and domain-driven design (DDD) are related in that software architecture views
provide a way to represent and communicate the structure and behavior of a software system, while DDD
provides a way to model and design the domain of the problem space that the software system is addressing.

In DDD, the domain model is the central artifact that captures the concepts, entities, and behaviors of the problem
space. It provides a shared understanding of the domain and serves as a basis for communication between domain
experts and software developers. The domain model is typically structured in multiple levels of abstraction, where
higher-level models are refinements of lower-level models.

Similarly, in software architecture, multiple views are used to represent the different aspects of a software system.
Each view provides a different "zoom factor" and level of abstraction, allowing stakeholders to focus on different
aspects of the system. For example, a deployment view might show the physical hardware and network
infrastructure, while a component view might show the software components and their dependencies

The concept of refinement in software architecture views is similar to the concept of refinement in DDD's
modeling approach. Both involve modeling a problem space at different levels of abstraction, and refining higher-
level models to produce lower-level models. In DDD, this might involve refining a high-level domain model into more
detailed entity models and aggregate models. In software architecture, this might involve refining a high-level
system architecture view into more detailed views of specific components or subsystems.

Overall, the concept of refinement in software architecture views and in DDD is a way to manage complexity and
provide a shared understanding of the system and the problem space. By breaking down complex systems and
models into smaller, more manageable parts, it becomes easier to reason about and communicate the system's
behavior and structure.

In the logical view they relate as it contains data entities. There is no contradiction between them. They both provide
simplified overview of the complex system and make it more understandable. Both support different project
stakeholders by providing relevant information for each of them.

DDD is a set of rules that allow you to make the right design decisions. This approach can significantly accelerate the
process of designing software in an unfamiliar domain. Architecture views are part of the documentation that
describes the architecture. Architecture views are motivated by stakeholders’ concerns. These concerns specify the
viewpoint on the architecture and, thus, specify the views.

One possible way in which the software architecture view concepts and domain-driven design relate would be that
both concepts offer suppport for different stakeholders (e.g. developers, business analysists) in understanding the
complex systems better. One of the domain-driven design premise is to initiate a creative collaboration between
technical and domain experts to iteratively cut ever closer to the conceptual heart of the problem

52
Task 02: Studying the Zachman framework

Explain how it relates to the concepts introduced in the lecture and to the 4+1 view model.

The Zachman Framework can be seen as a higher-level framework for organizing and relating different software
architecture views, such as the 4+1 view model. In the Zachman Framework, each cell can be thought of as
representing a particular view of the enterprise, which can correspond to one of the views in the 4+1 model, such
as the logical or physical view. Similarly, the different aspects of the Zachman Framework can be mapped to the
different dimensions of the 4+1 model, such as the process or data dimension.

In terms of domain-driven design, the Zachman Framework can provide a high-level structure for organizing and
relating different models and concepts within a domain. The different cells in the Zachman Framework can represent
different domains or subdomains within an enterprise, and the different models or artifacts associated with each cell
can represent different aspects of the domain or subdomain. This can help ensure that the different models and
concepts in a domain-driven design are organized and related in a coherent and consistent way.

In summary, the Zachman Framework provides a high-level framework for organizing and relating different software
architecture views, which can be mapped to the different views in the 4+1 model. The Zachman Framework can also
provide a structure for organizing and relating different models and concepts in domain-driven design.

A framework for enterprise architecture, which provide a formal and highly structured way of viewing and defining
an enterprise. What is more, it is based around the principles of classical architecture that establish a common
vocabulary and set of perspectives for describing complex enterprise systems. The Zachman Framework has six
perspectives or views: Planner, Owner, Designer, Builder, Subcontractor, and User. The second dimension of
Zachman’s Framework deals with the six basic questions: what, how, where, who, when and why. The framework
does not provide guidance on sequence, process, or implementation, but rather focuses on ensuring that all views
are well established, ensuring a complete system regardless of the order in which they were established. So from
this, it would show a strong focus on logical & physical view. The audience perspective which is the very left
column are the zoom factors for different stakeholders. The columns data & function are related to the logical and
process view. The network column relates to the physical view and time & motivation refer to the process view.

Zachman framework:
The Zachman Framework is an enterprise ontology and is a fundamental structure for Enterprise Architecture which

53
provides a formal and structured way of viewing and defining an enterprise. It is an ontology whereby a schema for
organizing architectural artifacts (in other words, design documents, specifications, and models) is used to take into
account both who the artifact targets (for example, business owner and builder) and what particular issue (for
example, data and functionality) is being addressed. This framework is explained as, for example:

 a framework to organize and analyze data,

 a framework for enterprise architecture.

 a classification system, or classification scheme

 a matrix, often in a 6x6 matrix format

 a two-dimensional model or an analytic model.

 a two-dimensional schema, used to organize the detailed representations of the enterprise.

The Zachman Framework summarizes a collection of perspectives involved in enterprise architecture. The
framework is a logical structure for classifying and organizing the descriptive representations of an enterprise. It is
significant to both the management of the enterprise, and the actors involved in the development of enterprise
systems. The basic idea behind the Zachman Framework is that the same complex thing or item can be described for
different purposes in different ways using different types of descriptions. The Zachman Framework provides the
thirty-six necessary categories for completely describing anything; especially complex things like manufactured
goods (e.g., appliances), constructed structures (e.g., buildings), and enterprises

Task 03: Relating UML and the 4+1 View Model

The ISO/IEC/IEEE 4[Link] Systems and software engineering — Architecture description standard was adopted
Dec 20112. The provisions of this International Standard serve to:

 enforce desired properties of architecture descriptions

 enforce desired properties of architecture frameworks and architecture description languages (ADLs)
 provide a basis on which to compare and integrate architecture frameworks and ADLs by providing a
common ontology for specifying their contents

It defines the relationships of views and viewpoints to many other architectural terms. How do the following terms
fit into the following incomplete class diagram?

• Architecture Viewpoint

• Architecture View

• System of interest

• Architecture

• Stakeholder

• Concern

• Architecture Model

• Model Kind

54
Task 04: Extracting information from use case template
Here is an example use case:

Use Case: 5 Buy Goods

CHARACTERISTIC INFORMATION

Goal in Context: Buyer issues request directly to our company,

expects goods shipped and to be billed.
Scope: Company
Level: Summary
Preconditions: We know Buyer, their address, etc.
Success End Condition: Buyer has goods, we have money for the goods.
Failed End Condition: We have not sent the goods, Buyer has not spent the
money.
Primary Actor: Buyer, any agent (or computer) acting for the customer
Trigger: purchase request comes in.

MAIN SUCCESS SCENARIO

1. Buyer calls in with a purchase request.
2. Company captures buyer’s name, address, requested goods, etc.
3. Company gives buyer information on goods, prices, delivery dates, etc.
4. Buyer signs for order.
5. Company creates order, ships order to buyer.
6. Company ships invoice to buyer.
7. Buyers pays invoice.

RELATED INFORMATION
Priority: top
Performance Target: 5 minutes for order, 45 days until paid
Frequency: 200/day
Superordinate Use Case: Manage customer relationship (use case 2)
Subordinate Use Cases:
Create order (use case 15)
Take payment by credit card (use case 44)
Handle returned goods (use case 105)
Channel to primary actor: may be phone, file or interactice
Secondary Actors: credit card company, bank, shipping service
Channels to Secondary Actors:

55
Task 05: Use Cases and Views for an Energy Provider System (NOT
ANSWERED)
Consider the following three short, initial use cases for the system of an energy provider to support their
customers in accessing their services using web browsers and mobile devices. They allow customers to log in (Use
Case 1), submit their meter readings (Use Case 2), and view their bill amount (Use Case 3), providing a convenient
and efficient way for customers to manage their energy usage and manage their payments. The energy provider
can also provide meter readings. Based on the information provided, provide a UML-based DDD model for the
logical view and a UML-based component model for the development view. You can freely design aspects that are
not specified in the use cases.

Use Case: Login

Actors: Customer
Description: Allows the customer to log in to the system.
Preconditions: Customer has internet access and a valid account with the energy provider.
Postconditions: Customer is logged in to the system and can access their account information.
MAIN SUCCESS SCENARIO
1. The customer navigates to the energy provider's website or mobile app.
2. The system displays a login screen.
3. The customer enters their username and password.
4. The system verifies the customer's credentials and logs them in.
5. The system displays the customer's account information.

Use Case: Submit Meter Reading

Actors: Customer
Description: Allows the customer to submit electricity and gas meter readings.
Preconditions: Customer has logged in to the system.
Postconditions: The system records the meter reading and calculates the bill amount.
MAIN SUCCESS SCENARIO
1. The customer navigates to the "Submit Meter Reading" section.
2. The system displays a form for the customer to enter their meter readings for electricity and gas.
3. The customer enters the meter readings and submits the form.
4. The system records the meter readings and calculates the bill amount.
5. The system sends a notification to the customer on the successful submission of meter
readings.

Use Case: View Bill Amount

Actors: Customer
Description: Allows the customer to view the bill amount.
Preconditions: The customer has logged in to the system and submitted the meter readings.
Postconditions: The customer is able to view the calculated bill amount.
MAIN SUCCESS SCENARIO
1. The customer navigates to the "View Bill Amount" section.
2. The system displays the customer's current bill amount based on the meter readings submitted.
3. The customer can view the bill amount and due date.
4. The system sends the bill amount to the customer's email.

56
SE-Quizzes 03
Based on the above diagram, which of the following statements are correct?

a. The same content as this diagram illustrates, could also be represented by

activity and class diagrams. It intends to show the processes throughout the
application.

b. This diagram belongs to the Logical View of the 4+1 Views Model because it
shows the structural elements and key abstractions (in terms of classes) that
are necessary to realize the application’s functionality.

c. All components from the Development View must be represented in this type of diagram.

d. This development diagram of a Telemedicine System shows how the software is packaged into components.

e. This deployment diagram of a Telemedicine System shows the physical disposition of artifacts in the real-world
setting.

f. In the context of Domain-Driven Design, this type of diagram must be kept generic and technology-agnostic, as the
specific technologies are choices left for the implementers of the model.

Answer: c, e, f (nur e)

Based on the above use case diagram, which of the following statements are correct?

a. This diagram is part of the non-redundant physical view of

the 4+1 Views Model.

b. This type of diagram is often supplemented or replaced by

textual descriptions.

c. This type of diagram is used to depict the interaction of

human actors with the modelled system, whereas
deployment diagrams are used to model the interaction with
external devices.

d. This type of diagram is used to depict the Scenarios View

of the modelled system, and in the context of the 4+1 Views
Model is the redundant view in the model.

e. The architecture of the underlying system will at least partially evolve from the contents modeled by this diagram.

Answer: b, e, d

Based on the above diagram, that shows how a shopkeeper selects products for sale, which of the following
statements are correct?

a. Selecting the product and calculating the price refers to the

physical-level artifacts of the system. For this reason, the diagram
can be viewed as part of the Development View.

b. This diagram provides information on the deployment and

components of the underlying application and is therefore part of
the Process View from the 4+1 Views Model.

c. This diagram represents a domain model for the Logical View.

57
d. This diagram models a scenario how the product is selected, the quantity is checked and the price is calculated by
the shopkeeper. It could therefore form part of the Scenarios View of the 4+1 Views Model.

Answer: d

Based on the above diagram, which of the following statements are correct?

a. The lifelines depicted in the diagram represent the physical-level artifacts at the conceptual level.

b. This diagram is a sequence diagram, which means that it helps to model simple system processes by breaking
down the interactions between the various system objects.

c. This type of diagram is used mainly to model interactions between users (i.e., human actors) and the system.

d. To be a valid part of the 4+1 Views Model, this type of diagram needs to model all possible interaction paths of the
system.

e. The calls ranging from loginUser to getPatientMonitoringList visualize the use cases of this scenario.

f. This type of diagram could be used as part of the Process View in the 4+1 Views Model.

Answer: b, f

Based on the depicted use case diagram, which of the following statements are correct?

a. This diagram models the main use cases of the Online Banking System.

b. The use cases for the two actors, Account Holder and Bank Advisor, could be further detailed in textual form by
the means of a use case template. Each use case would be described in one template instance.

c. This type of diagram needs to be complete (i.e., a use case diagram must contain all use cases that the system has)
in order to be counted as part of the 4+1 Views Model.

d. For the Scenarios View, one could also represent the same content (as given in the above diagram) by using a
deployment diagram.

Answer: a, b

58
 [Link] The Architecture
Part 1
4.1
Layers

59
4.2 Organizing Domain

Logic

60
4.3 Shared Repository

61
Worksheet 04: Patterns for Structuring the Architecture
Task 01: Audacity
The following text from: [Link] explains the component

structure of Audacity. Audacity is a popular sound recorder and audio editor. Is this a layered

architecture? If yes, explain which layers are used and how? If no, explain why.
"Audacity is layered upon several libraries. While most new programming in Audacity code doesn't require a detailed knowledge of exactly
what is going on in these libraries, familiarity with their APIs and what they do is important. The two most important libraries are PortAudio
which provides a low-level audio interface in a cross-platform way, and wxWidgets which provides GUI components in a cross-platform way.

When reading Audacity's code, it helps to realize that only a fraction of the code is essential. Libraries contribute a lot of optional features
though people who use those features might not consider them optional. For example, as well as having its own built-in audio effects, Audacity
supports LADSPA (Linux Audio Developer's Simple Plugin API) for dynamically loadable plugin audio effects. The VAMP API in Audacity does the
same thing for plugins that analyze audio. Without these APIs, Audacity would be less feature-rich, but it does not absolutely depend on these
features.
Other optional libraries used by Audacity are libFLAC, libogg, and libvorbis. These provide various audio compression formats. MP3 format is
catered for by dynamically loading the LAME or FFmpeg library. Licensing restrictions prevent these very popular compression libraries from
being built-in.

Licensing is behind some other decisions about Audacity libraries and structure. For example, support for VST plugins is not built in because of
licensing restrictions. We would also like to use the very efficient FFTW fast Fourier transform code in some of our code. However, we only
provide that as an option for people who compile Audacity themselves, and instead fall back to a slightly slower version in our normal builds.
As long as Audacity accepts plugins, it can be and has been argued that Audacity cannot use FFTW. FFTW's authors do not want their code to
be available as a general service to arbitrary other code. So, the architectural decision to support plugins leads to a trade-off in what we can
offer. It makes LADSPA plugins possible but bars us from using FFTW in our pre-built executables.

Architecture is also shaped by considerations of how best to use our scarce developer time. With a small team of developers, we do not have
the resources to do, for example, the in- depth analysis of security loopholes that teams working on Firefox and Thunderbird do. However, we
do not want Audacity to provide a route to bypass a firewall, so we have a rule not to have TCP/IP connections to or from Audacity at all.
Avoiding TCP/IP cuts out many security concerns. The awareness of our limited resources leads us to better design. It helps us cut features that
would cost us too much in developer time and focus on what is essential.

A similar concern for developers' time applies to scripting languages. We

want scripting, but the code implementing the languages does not need to
be in Audacity. It does not make sense to compile copies of each scripting
language into Audacity to give users all the choices they could want. We
have instead implemented scripting with a single plugin module and a pipe,
which we will cover later.
Figure 2.1 shows some layers and modules in Audacity. The diagram
highlights three important classes within wxWidgets, each of which has a
reflection in Audacity. We're building higher-level abstractions from related
lower-level ones. For example, the BlockFile system is a reflection of and is
built on wxWidgets' wxFiles. It might, at some stage, make sense to split
out BlockFiles, ShuttleGUI, and command handling into an intermediate
library in their own right. This would encourage us to make them more
[Link] down in the diagram is a narrow strip for "Platform Specific
Implementation Layers." Both wxWidgets and PortAudio are OS
abstraction layers. Both contain conditional code that chooses between
different implementations depending on the target platform.

The "Other Supporting Libraries" category includes a wide collection of libraries. Interestingly quite a few of these rely on dynamically loaded
modules. Those dynamic modules know nothing of wxWidgets.

On the Windows platform we used to compile Audacity as a single monolithic executable with wxWidgets and Audacity application code in the
same executable. In 2008 we changed over to using a modular structure with wxWidgets as a separate DLL. This is to allow additional optional
DLLs to be loaded at run time where those DLLs directly use features of wxWidgets. Plugins that plug in above the dotted line in the diagram
can use wxWidgets.
The decision to use DLLs for wxWidgets has its downsides. The distribution is now larger, partly because many unused functions are provided
in the DLLs that would previously have been optimized away. Audacity also takes longer to start up because each DLL is loaded separately. The
advantages are considerable. We expect modules to have similar advantages for us as they do for Apache. As we see it, modules allow the core
of Apache to be very stable while facilitating experimentation, special features and new ideas in the modules. Modules go a very long way to

62
counteracting the temptation to fork a project to take it in a new direction. We think it's been a very important architectural change for us.
We're expecting these advantages but have not seen them yet. Exposing the wxWidgets functions is only a first step and we have more to do
to have a flexible modular [Link] structure of a program like Audacity clearly is not designed up front. It is something that develops over
time. By and large the architecture we now have works well for us. We find ourselves fighting the architecture when we try to add features
that affect many of the source files. For example, Audacity currently handles stereo and mono tracks in a special cased way. If you wanted to
modify Audacity to handle surround sound you'd need to make changes in many classes in Audacity."

Answer:
Yes, Audacity is a layered architecture. It is built on top of several libraries, including PortAudio and wxWidgets,
which provide cross-platform low-level audio interface and GUI components respectively. In addition to these two
libraries, Audacity also uses optional libraries for various audio compression formats and plugin APIs, such as LADSPA
and VAMP. The architecture of Audacity is shaped by licensing restrictions, limited developer time, and a desire for
modularity. The layered structure of Audacity allows for the separation of concerns and promotes the reuse of
existing libraries and APIs.

Task 02: Structuring an architecture

There are the following components and relationships in an application for booking:

 “Book Web Application” connected via JMS connector to “Notification Engine”

 “Notification Engine” connected via SMTP connector to “Mail Server”
 “Book Service” connected via Java invocation connector to “Book Repository”
 “Book Web Service” connected via JMS connector to “Notification Engine”
 “Maven Plug-in” connected via REST connector to “Book Web Service”
 “Brower” connected with an HTTP connector to “Book Web Application”
 “Book Web Application” connected via Java invocation connector to “Book Service”
 “Book Web Service” connected via Java invocation connector to “Reporting Service”
 “Reporting Service” connected via Java invocation connector to “Book Repository”
 “Book Repository” connected via JDBC connector to “Data Store”

Design a layered architecture based on these components and their connectors

Based on the given components and relationships, a layered architecture can be designed as follows:

Presentation Layer: This layer includes the "Browser" and the "Book Web Application" components. The "Browser"
component connects with an HTTP connector to the "Book Web Application", which provides the user interface for
booking.

Business Logic Layer: This layer includes the "Book Service", "Book Web Service", and "Notification Engine"
components. The "Book Service" component connects via Java invocation connector to the "Book Repository"
component, which is responsible for managing the book data. The "Book Web Service" component connects via JMS
connector to the "Notification Engine" component, which sends notifications to users.

Integration Layer: This layer includes the "Maven Plug-in" component, which connects via REST connector to the
"Book Web Service" component.

Data Access Layer: This layer includes the "Book Repository" component, which connects via JDBC connector to the
"Data Store" component, where the book data is stored.

Reporting Layer: This layer includes the "Reporting Service" component, which connects via Java invocation
connector to the "Book Repository" component, to generate reports based on the book data.

Additionally, the "Notification Engine" component connects via SMTP connector to the "Mail Server" component to
send email notifications. The "Book Web Application" component connects via JMS connector to the "Notification
Engine" component for sending notifications to users.

Task 03: Relation to domain-driven design

What is the relation of the patterns Layers, Transaction Script, and Domain Model to domain-driven design?
63
The patterns Layers, Transaction Script, and Domain Model are all related to domain-driven design (DDD) in different
ways:

Layers: Layers is a design pattern that is commonly used in domain-driven design to structure the application into
different layers of abstraction. In DDD, the most common layers are the presentation layer, application layer, domain
layer, and infrastructure layer. Each layer has a specific responsibility, and the layers are designed to be loosely
coupled, making it easier to change one layer without affecting the others.

Transaction Script: Transaction Script is a design pattern that is often used in simple applications where the business
logic is straightforward and doesn't require a lot of complexity. It's not typically used in domain-driven design, as
DDD usually involves more complex business logic that requires a more sophisticated approach.

Domain Model: Domain Model is a design pattern that is a core part of domain-driven design. It involves creating a
rich and expressive model of the domain that captures the essential concepts, behaviors, and relationships of the
domain. The Domain Model is usually implemented using object-oriented programming and is intended to be a
reflection of the real-world domain.

In summary, Layers and Domain Model are key design patterns in domain-driven design, while Transaction Script is
not typically used in this approach.

Task 04: Task: Transaction Script vs. Domain Model

Below you see a sequence diagram for a Transaction Script and a Domain Model based solution¹.

a) What are the major differences of the patterns in terms of the behavior (illustrated using this example)?

b) Why is using the data gateway a good idea in the Transaction Script case?

c) "Object-relational mapping (ORM, O/RM, and O/R mapping tool) in computer science is a programming
technique for converting data between incompatible type systems in object-oriented programming languages.
This creates, in effect, a "virtual object database" that can be used from within the programming language.2" Can
ORM be used in one of those example? What is the relation of ORM to a Data Gateway?

d) "An object database (also object-oriented database management system, OODBMS) is a database management
system in which information is represented in the form of objects as used in object- oriented programming.3" Can
an object database be used in one of those example? What is the relation of an object database to a Data
Gateway?

BOOK EXCERPT:

64
65
66
67
68
Task 05: Structuring an architecture
a) Design a system architecture as a box and line (or component) diagram with the following (in part technical)
requirements:
 Users interact with the system using a dedicated Ul. The UI consists of UI components and components
realizing the presentation logic.
 Service Consumers in external systems can interact with the system using service interfaces. UI
components and components realizing the presentation logic require the same interfaces as the service
Consumers in external systems.
 Service interfaces abstract the business components, business entities, and business workflows.
 Business components, business entities, and business workflows operate on various data sources and
external systems.
 Data sources and external systems are not accessed directly, but using data access components, data
utilities, and service agents.
 All components must be secured so that unauthorized access is not possible.
 Operational management must be supported by all components (like being able to start, pause, and stop
components and see their status in a console).
 Communication is handled between components through in memory invocations and specific
communication protocols.
User Interaction: This component provides the UI for the users to interact with the system. It includes UI
components and components realizing the presentation logic.

Presentation Logic: This component is responsible for handling user input, validating user input, and providing
feedback to the user. It communicates with the Business Components through Service Interfaces.

Service Interfaces: This component abstracts the Business Components, Business Entities, and Business Workflows. It
provides an interface for external systems to interact with the system. It also provides an interface for the
Presentation Logic to interact with the Business Components.

Business Components: This component includes the core business logic of the system. It operates on various data
sources and external systems through Data Access Components, Data Utilities, and Service Agents.

Data Access Components, Data Utilities, and Service Agents: These components are responsible for interacting with
Data Sources and External Systems. They are used by the Business Components.

External Systems: These are external systems that interact with the system through Service Interfaces.

Security: All components in the system must be secured so that unauthorized access is not possible.

Operational Management: All components must support operational management, such as the ability to start,
pause, and stop components and see their status in a console.

Communication: Communication between components is handled through in-memory invocations and specific
communication protocols.
b) Does it make sense that the architecture follows the Layers pattern? Say why and how. Does it make sense that
a possible design follows the principle 3 Layers for Enterprise Architectures?
Yes, it makes sense for the architecture to follow the Layers pattern since it helps to organize the system's
components and responsibilities in a clear and concise way. The Layers pattern separates the system into layers
where each layer has a specific responsibility and interacts only with adjacent layers. This separation of concerns
promotes modularity, reusability, and flexibility in the system.

Following the principle of 3 Layers for Enterprise Architectures would also make sense as it provides a standardized
approach to layering the system's components. The three layers are typically named presentation layer, business
logic layer, and data access layer. The presentation layer handles user input and output, the business logic layer
handles the business rules and workflows, and the data access layer handles data storage and retrieval.

69
By following this principle, the system can be designed to have a clear separation of concerns, which can facilitate
development and maintenance of the system over time. It also promotes flexibility, allowing changes to be made to
one layer without affecting the others, which can simplify testing and debugging efforts.

c) Can you apply the Domain Model or Transaction Script patterns? Say why and how.
Yes, both the Domain Model and Transaction Script patterns can be applied to this system architecture.

The Domain Model pattern could be used to represent the business logic of the system, which operates on various
data sources and external systems. Business components, entities, and workflows can be defined and modeled in a
way that reflects the business domain, and service interfaces can be used to abstract these components from the
outside world. This can provide a clear separation between the business logic and the presentation layer, as well as
enable the reuse of business components across different parts of the system.

The Transaction Script pattern could be used to represent the presentation logic of the system, which interacts with
the UI components and handles user input. Each user action could be implemented as a separate transaction script,
which interacts with the necessary business components and entities to carry out the requested action. This can
provide a straightforward and easy-to-understand way of handling user input, as well as make it easier to modify and
extend the system over time. However, it may not be the best approach if the system has complex business logic or
if there is a need for a more modular and scalable design.

d) How does this architecture relate to the Shared Repository pattern? Are benefits or downsides of the Shared
Repository pattern manifesting in this architecture?
The Shared Repository pattern is a design pattern that suggests that all application layers should share a single data
source and that data access should be done through a single shared repository. In this architecture, the business
components, entities, and workflows operate on various data sources and external systems. Therefore, it doesn't
follow the Shared Repository pattern.

The benefits of the Shared Repository pattern include:

Improved consistency: A single data source ensures that data is consistent across all application layers.
Simplified maintenance: Having a single data source simplifies the maintenance of the application as all data access
and management can be done through the shared repository.
Reduced coupling: The use of a single data source reduces coupling between application layers, making it easier to
change one layer without affecting the others.
The downsides of the Shared Repository pattern include:

Scalability issues: A single data source can become a bottleneck as the application scales.
Increased complexity: The use of a shared repository can increase the complexity of the application, especially when
dealing with complex data structures.
Reduced flexibility: The use of a shared repository can reduce the flexibility of the application as all layers must use
the same data source and schema.
Since this architecture does not follow the Shared Repository pattern, its benefits and downsides are not manifesting
in this architecture.

70
SE-Quizzes 04
Based on the depicted model, which of the following statements are correct?
a. This model could benefit from introducing a simple data source layer, but once the domain becomes more
complex it would further complicate the implementation.
b. This model depicts a Transaction Script Pattern, which means that it is organized around the main nouns in the
UniversityCourse domain.
c. This model can handle complex domain logic, but has the disadvantage that its mapping to the database
(especially relational) can become complex.
d. This model represents the Domain Model Pattern, which means that it organizes the main nouns of the domain
(e.g. the Review and the UniversityCourse) as procedures with a single request.
Answer: c

Based on the depicted model (figure 2), which of the following statements are correct?
a. The above model is very flexible offering each dependent component different technical means for accessing the
data.
b. This model represents the Shared Repository Pattern, which means that it uses a database to centrally store the
data of multiple system components.
c. The problem of the pattern represented in the above model is that performance and scalability issues might arise
as the system becomes more complex and/or the number of transactions increases.
d. The above model is an example of the Shared Repository Pattern, which uses decentralized data storage and
eventual consistency.

Figure 2
Figure 3
71
Based on the depicted model (figure 3), which of the following statements are correct?
a. The drawback of the modeled OrderService as shown above is that it becomes difficult to extend the
implementation as the domain complexity increases.
b. In order to transform this model into a Domain Model Pattern, it should rather be organized around objects
derived from the main nouns in the domain. In doing so, the model would tightly couple the behavior and the data.
c. The above OrderService model organizes business logic in a single class following the transaction script pattern.
d. The model is structured according to the Domain Model Pattern. The benefit of using this pattern is that the
OrderService can deal with increasingly complex domain logic.
Answer: a, b, c
Based on the depicted model (figure 4), which of the following
statements are correct?
a. The various layers in the model need to know every other layer of the
model well, so that information and commands can be transferred across
all layers.
b. The above model supports the aim of minimal dependencies between
the system parts because the layers are clearly separated and clear
interfaces are provided between them.
c. "Data Access" in this model refers to communication, for example with
databases and data-related transaction managers.
d. The "User Interface Components" part denotes the Domain Layer of the
model.
Answer: c
Based on the above model (figure 4), which of the following statements
are correct?
a. The above model tries to decouple the components in a horizontal way.
b. The "User Interface Components" part represents the Presentation Logic Layer. Figure 4
c. The above model implements a Layers pattern. This means that each layer provides a set of services to the layer
above.
d. In the "Workflows and Business Entities" part of the model, the communication with databases, messaging
systems and data in general occurs.

72
 [Link] the
Architecture Part 2
5.1 Model-View-Controller

73
5.2 Pipes and

Filters

5.3 Publish/Subscribe Pattern

74
75
Worksheet 05:Patterns for Structuring the Architecture
(Part 2)
Task 01: Ruby-on-Rails Architecture
Below you see a diagram showing the MVC architecture of Ruby on Rails (in more detail then in the lecture slides)

There are a number of differences to the schematic MVC architecture from the lecture.

Explain those differences and for each give a plausible reason why an alternative variant of MVC has been
designed.

 MVC’s main purpose is to create multiple views, ruby-on-rails only has one.
 Dispatcher extracts all information and directly gives it to controller.
 The Action Controller performs CRUD (Create, Read, Update, Delete) operations on the Active Record (Stores
ruby objects persistenly). The model and notification mechanism is as follows:
-Model in the Active Record. It serves as a wrapper to the database
-Notification is in the Action Controller Redirect connection and in the rendering of the view.
 In theory, Ruby on Rails does not really follow the MVC standards, because in Rails, the model data gets sent
to the view via the controller, and it is the controller that returns the HTML output back to the browser.

Model (ActiveRecord ) - It maintains the relationship between the objects and the database and handles validation,
association, transactions, and more.

This subsystem is implemented in ActiveRecord library, which provides an interface and binding between the tables
in a relational database and the Ruby program code that manipulates database records. Ruby method names are
automatically generated from the field names of database tables.

View ( ActionView ) - It is a presentation of data in a particular format, triggered by a controller’s decision to present
the data. They are script-based template systems like JSP, ASP, PHP, and very easy to integrate with AJAX
technology.

This subsystem is implemented in ActionView library, which is an Embedded Ruby (ERb) based system for defining
presentation templates for data presentation. Every Web connection to a Rails application results in the displaying of
a view.

76
Controller ( ActionController ) - The facility within the application that directs traffic, on the one hand, querying the
models for specific data, and on the other hand, organizing that data (searching, sorting, messaging it) into a form
that fits the needs of a given view.

This subsystem is implemented in ActionController, which is a data broker sitting between ActiveRecord (the
database interface) and ActionView (the presentation engine).

Why has an MVC architecture been chosen for the Ruby on Rails architecture?

The MVC allows a clean separation of concerns , in the way that it keeps the business logic separated from the HTML
views. Additionally, it improves decoupling and testing.

What are the disadvantages of using MVC here?

The complexity is high to develop the applications using this pattern.

Not right suitable for small applications which have adverse effect in the application’s performance and design.

In term of servlet and JSP, both often contains business logic and presentation tier.

The isolated development process by UI authors, business logic authors and controller authors may lead to delay in
their respective modules development.

Task 02: Studying Pipes and Filters

Here is an example of a Pipes and Filters architecture from [Link]
with the task of “cleaning” incoming orders.

a) Is this a good example for the use of pipes and filters?

Generally, yes, all benefits of the pattern apply:

 Improved reusability
 Improved performance
 Improved changeability
 Reduced coupling

b) Messaging middleware is used as a pipe mechanism. Below is a brief summary of the messaging concept. Is this
a good idea?

Generally, messaging is a good solution, because it manages the exchange of messages between services accross the
network, and eorror information. Though message queues, messaging allows for the reliable delivery of messages
and temporal decoupling of sender and receiver.

77
If the whole process of “cleaning orders” is at one server than the benefit of messaging (reliable communcation) is
not needed.

c) Which benefits and downsides of the pattern are reflected in this architecture?

Benefits:

 Good mechanism to use messaging of the shelf.

 Decomposes a complex processing task into a series of discrete elements.
 Flexible use of different mechanisms/transformations which should be robust

Downsides:

 An application may be required to perform a variety of tasks of varying complexity on the information that it
processes.
 If a filter needs to wait until it has reeived all data (e.g. a sort filter), its data buffer may overflow, or it may
deadlock.
 If the pipes only allow for a single data type (a character or byte) the filters will need to do some parsing.
This complicates te things and slows them down. If you create diffrent pipes for diffrent datatypes, you
cannot link any pipe to any filter.

Additional information on Message Router:

How can you decouple individual processing

steps so that messages can be passed to
different filters depending on a set of
conditions? Insert a special filter, a Message
Router, which consumes a Message from one
Message Channel and republises it to a
different Message Channel depending on a
set of conditions.

Additional information on Message Channel:

How does one application communicate

with another using messaging? Connect
the applications using a Message
Channel, where one application writes
information to the channel and the
other one reads that information from
the channel.

Task 03: Studying Pipes and Filters

Here is an example of a Pipes and Filters architecture from
[Link] for a printing Web service.

a) Is this a good example for the use of pipes and filters?

Answer: The example is based on pipes and filters pattern, but in lecture it was said that we need more information
to know exactly.

Main difference: only one data format is being exchanged, and in the end a document comes out, not a very
consistent use of one piping mechanism.

b) Messaging middleware is used as a pipe mechanism. Is this a good idea?

78
In general messaging middlware is a good way to implement pipe and filters pattern. The benefits are as follows:

 Good mechanism to use messaging of the shelf.

 Decomposes a complex processing task into a series of discrete
elements.
 Flexible use of different mechanisms/transformations which
should be robust

Downsides:

An application may be required to perform a variety of tasks of varying

complexity on the information that it processes.

If a filter needs to wait until it has reeived all data (e.g. a sort filter), its
data buffer may overflow, or it may deadlock.

If the pipes only allow for a single data type (a character or byte) the
filters will need to do some parsing. This complicates te things and slows
them down. If you create diffrent pipes for diffrent datatypes, you
cannot link any pipe to any filter.

c) Which benefits and downsides of the pattern are reflected in this

architecture?

Benefits:

 Improved reusability, performance and modifiability and reduced coupling.

Downsides:

 Increased complexity, communication overhead, hard error handling, increased maintainability effort, hard
to access the states.

In more Detail:

 Separation of concerns. Each filter solves a different problem.

 Division of labour. ACORD XML experts implement the conversion of the proprietary ions into an internal
vendor-independent format. People who specialise in dealing with the intricacies of each jurisdiction assist
with the implementation of the filter that handles those aspects. Formatters and layout experts implement
document generation.
 Specialization. Document-rendering is CPU intensive and, in the case of a PDF document, uses float point
operation. You can deploy the rendering to hardware that meets these requirements.
 Reuse. Each filter encapsulates fewer context specific assumptions.

Task 04: Combining Layer and Pipes and Filters

Can the patterns Layers and Pipes and Filters be combined in one architecture? If yes, explain the options and give
an example per option. If no, explain why.

Answer 1: (ChatGPT)
Yes, it is possible to combine the Layers and Pipes and Filters patterns in one architecture. There are several options
for doing so:

Separate layers with filters: In this option, the Layers pattern is used to separate the application into different layers,
and the Pipes and Filters pattern is used to process data as it moves between the layers. Each layer has its own set of
filters that process data as it passes from one layer to the next. For example, a web application could have a
presentation layer, a business logic layer, and a data access layer, with filters in between each layer to process data.
79
Filtered Layers: In this option, the Layers pattern is used to separate the application into different layers, and the
Pipes and Filters pattern is used to process data within each layer. Each layer has its own set of filters that process
data within the layer. For example, a web application could have a presentation layer with filters for input validation,
a business logic layer with filters for caching and logging, and a data access layer with filters for database connection
management.

Layered Filters: In this option, the Pipes and Filters pattern is used to process data as it moves between layers, and
the Layers pattern is used to organize the filters into layers. Each layer contains a set of filters that process data as it
moves between the layers. For example, a web application could have a set of filters for input validation in the
presentation layer, a set of filters for caching and logging in the business logic layer, and a set of filters for database
connection management in the data access layer.

Overall, combining the Layers and Pipes and Filters patterns can provide benefits such as improved modularity,
flexibility, and reusability of components. However, it can also increase the complexity of the architecture and
require careful design and management of the filters.

Answer 2 (HegeDoc):

Layered Architecture is hierarchical architecture; it views the entire system as - hierarchy of structures. The software
system is decomposed into logical modules at different modules at different levels of hierarchy.

Pipe and Filter is a Data-Flow architecture, it views the entire system as -series of transformations on successive sets
of data and operations on it are independent of each other.

Yes, they can be combined. The main difference between the two architectural styles are the flow of data. In the
Layer e.g. TCP-IP it goes from the Client in the Application Layer down to the Physical Layer and then again back to
the first one, the data flows vertically. In contrast to Pipe-and-Filter where the client gets the result from the last
component, the data flows horizontally.

Options:

 Pipes&Filters support the vertical flow through the layers (Layered Filters)
 Pipe&Filters are used between the two layers (Separate layers with filters)
 Pipe&Filters are used horizontally in a layer, e.g. data cleaning (Filtered Layers)

ad 2) Use a Supoort Layer that

serves a s a data buffer and process
data in the pipes and filters
example from

80
Answer 3: The Pipes and Filters pattern could complement the LayersPattern in a natural way if the layers are
interpreted as a filter and the data flow as a pipe. For example, we have an input stream that has to be manipulated.
However, this can’t be implemented in a transformation step, if we have multiple developers involved, several
necesarry individual steps or the often-changeable requirements. So, we could combine the two patterns in the
following way: we structure pur overall system in layers, connect each neighboring filter (layer) with a pipe (data
flow), and implement an input and output channel for each filter.

Organization wise it may looks like both Layers and Pipe and Filters patters are similar (One component taking input
and passing result to another) but functionally they are not. They are Architectural Patterns.

If we go by definition:

Pipes and Filters pattern divide a larger processing task into a sequence of smaller, independent processing steps
(Filters) that are connected by channels (Pipes).

While in Layer Pattern, each layer communicates with the adjacent layers and is responsible for some processing of
its own, passing requests to the layer below it and answering requests from the layer above it.

Comparison:

The pipe and filter pattern allows a system to be assembled from small programs called filters whereas a Layered
system is one in which different layers of the system take care of a specific function of the system.

A filter has an input and an output whereas each layer in a layered architectural style is a package of software (or
systems) that has a well-defined interface and a few well-known dependencies within the application.

The filters are assembled into a chain in which each filter gets data from the previous filter in the chain, processes
the data, and passes the data to the next filter in the chain whereas in Layered systems dataflow can be bidirectional
such that all requests of layer above are fulfilled with or without help of layers below it.

Order may not matter. e.g. you can Authenticate a message and then filter the contents of the message, or you can
filter contents first then do authentication whereas in Layered system order is always same and cannot be
interchanged

Task 05: Studying an architecture

Here is an example of an architecture2 . Which of the patterns from the lecture are used here. Explain how and
why.

Publisher/Subscriber, 3-Tier
Architecture, Layer Pattern

81
Task 06: Designing an MVC/Shared Repository architecture
a) Design an MVC Web architecture based on Java Servlet technology with the following flow of events:

1. A Dispatcher Servlet receives requests

2. The Dispatcher Servlet then selects an appropriate Handler Mapping
3. Handler Mapping selects the appropriate MVC controller
4. Handler Mapping returns the MVC controller and Handler for the incoming request URL request to the
Dispatcher Servlet
5. The Dispatcher Servlet hands the task of executing of business logic to a Handler Adapter and
it also hands over the selected controller
6. Handler Adapter calls the business logic on the Controller 7. The Controller executes the business logic using a
Service
8. The Service uses a data access in a Shared Repository
9. The Controller sets the processing result in the Model and returns view ID to Handler Adapter, which returns to
Dispatcher Servlet
10. Dispatcher Servlet resolves the View ID using a View Resolver
11. The View Resolver returns the View corresponding to View ID
12. The Dispatcher Servlet dispatches the rendering process to the returned View

b) Why is the Shared Repository accessed in the

Controller and not in the Model?

Model is not Database, is not Repositories, is not

Entity. Model is abstraction, that contains all data,
that needs to be displayed. Controller prepares
Model, to pass it to View. Model should never format
data. It also should not read formatted data.

That is polluting the model and moving into the level

of hell where business logic = display logic. Controller
does not use Repository directly. Traditionally,
Controller works with Service, and Service uses
Repository to get data from database.

So relations are following: View <-Controller->Service->Repository/Model->View

It is a purpose of Controller to connect View and Model. Controller creates and fills the Model, then chooses View
and pass this created Model to the View.

Controllers - contains application logic and passing user input data ot service

Services - The middleware between controller and repository. Gather data from controller, performs validation and
business logic, and calling repositories for data manipulations.

Repositories: layer for interaction with models and performing DB operations

Models - common model files with relationships defined

82
SE-Quizzes 05
Based on the depicted model (figure 1), which of the following statements are correct?
a. The Controllers component takes user input only via the User Interface and transfers it by the means of a request to
the Domain layer.
b. The Domain Objects in Part B of the diagram are part of the "Model" in the Model-View-Controller pattern.
c. When using the Model-View-Controller pattern, the Application layer cannot consist of more than one View or User
Interface.
d. Part B is the Domain layer which contains the domain-specific logic
and objects.
Answer: a, b, d

Figure 1

Based on the depicted model (figure 1), which of the following

statements are correct?

a. The above model is an example of the Model-View-Controller

pattern in which the "View" is in Part A, the "Controller" in Part B and the "Model" in Part C.

b. The above model is a badly designed combination of the Model-View-Controller pattern and the Layers pattern
because the Domain-Specific Logic should be on a different layer than the User Interface.

c. Part C of the model corresponds to the Data Access layer; however, the Datastore should not be directly
connected to the Controllers.

d. Part B of the model corresponds to the Domain layer because it contains the Controllers, which directly access the
Datastore. Answer: b, c

Based on the depicted model, which of the following statements are correct?

a. The Publish/Subscribe pattern above increases the coupling between the model elements, and decreases the
complexity of communication by sending message events.

b. The Publish/Subscribe pattern above is incorrect. A published event should not be passed back to the Publisher
as indicated by the direct link pointing from a Subscriber to the Publisher.

c. In the Publish/Subscribe pattern above the producers are the Subscribers in the diagram and the consumer is the
Publisher.

d. The model above is incorrect because the

Publish/Subscribe pattern allows only one consumer
(Subscriber) to subscribe for receiving messages from
each producer (Publisher).

Answer: b)

83
Which of the following statements about the Publish/Subscribe pattern are correct?

a. In the Publish/Subscribe pattern, multiple topics can exist which have the same Publishers and Subscribers.

b. The Publishers and the Subscribers of a topic do not need to be located on the same machine. They can still
communicate if placed in different physical locations.

c. By the means of the Publish/Subscribe pattern, asynchronous communication between Publishers and various
interested Subscribers can take place.

d. The purpose of using the Publish/Subscribe pattern is to decouple the producer and the consumer of message
events.

Answer: a, b, c, d

Based on the depicted model, which of the following statements are correct?

a. The Pipes and Filters pattern helps to increase coupling between the various data streams needed on the client
side.

b. One implementation problem of the above model might be that the code to handle errors and to access the state
of the overall computation (distributed among multiple Pipe and Filter components) becomes more tedious.

c. The above model shows a schematic instance of the Pipes and Filters pattern, which is a design solution for
problems where variations of a complex computation on data-streams can be decomposed into a configurable
sequence of connected smaller tasks.

d. The Pipes and Filters pattern increases reusability of Pipes and Filter elements and improves changeability of the
architecture design.

Answer: b, c, d

84
 [Link] Exam Questions
Question 1:

Statement 1: The vocabulary of the “ubiquitous language” includes names of classes and prominent operations.

TRUE. Explanation: This language is used in the implementation process so that the implementation and domain
concept match because this language is based on the model and it is a unified language for all stakeholders to
connect all the attitudes of the team with the software. It includes terms to discuss rules that have been made
explicit in the model.

“ubiquitous language” means that every stakeholder agrees on the same terminoly (ontology) used within the
domain. Classes in the DDD domain should reflect important concepts of the domain, similarly operations should
reflect important actions within the domain.

Statement 2: The code and the “ubiquitous language” express different, and mutually exclusive, aspects of the same
model.

FALSE. Explanation: The model should use the language to express a common understanding among each
stakeholder so they are in the same line with every thing. such as the code and uniquitous language express the
same meaning.

The ubiquitous language is the language which developers use to discuss the domain model with stakeholders,
whereas code is the technical implementation of the domain model. There should be a large overleap in terminology
between code and the “ubiquitous language” and therefore, although they are separate concepts, are not mutually
exclusive.

Statement 3: Domain-Driven Design involves the creation of different domain models by the various stakeholder
groups, which are made compatible with each other by using a common “ubiquitous language”.

FALSE. Explanation: It has to be just one model, but iterated until there is a useful model to generate good
development by feedback coming from team members.

There are no different domain models per stakeholder group, but instead all stakeholders work on the same domain
model.

Question 2

Statement 1: In the model-view-controller pattern, changes to the data should be flexibly reflected, in the sense
that new user interfaces might be added and removed.

TRUE. Explanation: Changes to the data should be automatically and flexibly reflect to all UI. Should be easily
accessed to modify(add, remove) without affecting the application logic.

The strength of the MVC pattern (and related patterns such as MVVC and MVP) is that they decouple functionality
from the user interface.

Statement 2: The model-view-controller ensures the principle of “high cohesion – low coupling”.

TRUE. Explanation: Close coupling of views and controllers to a model that is needed to manipulate the data.

The user interface and the business logic are decoupled via controllers, which themselves should access only few
well-defined interfaces of the business model.

Statement 3: In the publish/subscribe pattern, the callback operation is responsible for informing the event
consumers about the event.

TRUE. Explanation: This pattern is triggered by event producers and automatically executes a callback operation to
the event consumers
85
Statement 4: If nothing can be parallelized in the filters of a pipeline, the performance is usually lowered.

TRUE. Explanation: If the filter can not be split into sub tasks than the performance is lowered.

Assuming a command flow of:

consumer - registers with (request callback on message) -> message handler

producer - notifies -> message handler

message handler -calls back -> consumer

Statement 5: In a layered architecture, a pipeline can go through different layers.

TRUE. These two patterns can be combined in a layered architecture to create a pipeline that goes through different
layers. For example, in a web application, user input could be handled by the presentation layer, then passed
through a series of filters in the business logic layer for processing, and finally stored in the data access layer. The
pipeline of data would flow through multiple layers, each layer processing the data in a different way.

Statement 6: In a layered architecture, tasks within a layer can be structured in a pipeline.

TRUE. Yes, it is true that in a layered architecture, tasks within a layer can be structured in a pipeline. A layer can
have its own internal structure and processing flow, which may involve multiple tasks being executed in a specific
sequence or in parallel. By organizing tasks in a pipeline within a layer, it can help to optimize the performance and
efficiency of the layer by reducing the need for unnecessary data transfers between layers. This can also help to
make the architecture more modular and easier to maintain.

Statement 7: There are no restrictions on how to combine the layers pattern with the pipes and filters pattern.

FALSE. Explanation: Even though the Pipe and Filter can be easily combined with repository pattern where filter can
access the repository, constraints with other layer pattern can be raised on how they are combined

In a layered architecture, layers should not be bypassed by other layers. In the pipes and filters pattern, the
composition of pipes and filters may vary, so hypothetically, unles restrictions are made, bypassing layers would be
possible.

Statement 8: Each filter or pipe of a pipeline can have a layered implementation.

TRUE. In a pipeline, each filter or pipe can be implemented using a layered architecture. This means that each filter
or pipe can have its own set of layers, allowing for separation of concerns and modularity within the filter or pipe.
Additionally, the layered implementation of each filter or pipe can be different from the implementation of other
filters or pipes in the pipeline, providing flexibility in the design of the overall system architecture.

Question 3

Based on the depicted diagram, that shows how a

shopkeeper selects products for sale, which of the
following statements are correct?

a) This diagram represents a domain model for the

Logical View.

b) This daigram provides information on the

deployment and components of the underlying
application and is therefore part of the Process View
from the 4+1 Views Model.

86
c) Selecting the product and calculating the price refers to the physical -evel artifacts of the system. For this reason,
the diagram can be viewed as part of the Development View.

d) This diagram models ascenario how the product is selected, the quantitiy is checked and the price is calculated by
the shopkeeper. It could therefore form part of the Scenarios View of the 4+1 Views Model.

Answer: d)

Question 4

Based on the depicted diagram

of an online movie ticket
booking system, answer the
following questions briefly, in
your own words

Question 1: Which use cases of

the system are represented in
the diagram?

Answer: User registration, User

login, Management of the
movies(methods: create,
remove, edit), View of the movies, Booking of the ticket(method makePayment()), Reservation cancellation

Question 2: Which actors can you identify? Can you think of any additional actors that might be relevant to the
processes/use cases shown?

Answer: Primary actors: Registered Customer, Visitor, Employee

Secondary actors: Ticket Manager and Payment Manager.

Question 3: Is MovieTheater to be modelled as part of your system or as an external entity? Explain why.

Answer: It has to be external not part of the system it just can be as an extra help for the system.

Movie Theaters very likely have their own system for tracking reservation (if only for historical reasons). It is
therefore safe to assume that they are external entities and should be modeled as such.

Question 4: This diagram is at a relatively high level of abstraction. Does this suffice in the context of a 4+1 Views
Model? Explain why, or why not.

Answer: In my opinion this sequence diagram depicts the main methods that would help to create the Logical View
that would be derived to achieve the building of the other 4+1 Views

So, yes, but only if other diagrams supplement the process view.

The 4+1 views model does not specify how many diagrams should be used to describe the arhitecture, only that
different perspectives on the system are present. The sequence diagram depicred shows how many different use
cases would be executed and could therefore be helpful in explaining the system to a non-technical stakeholder,
such as an executive. It lacks detail on the system-level implementation however, and would therefore make for
poor support in developing and documenting the actual system. Furthermore, activity or sequence diagrams would
consequently be needed to complete the process view.

87
Question 5

Based on the depicted model, which of the following

statements are correct?

a) The above model is an example of the Shared

REpository Pattern, which uses decentralized data
storage and eventual consistency.

b) The Shared Repository pattern is very flexible, in that it

offers each dependent component different technical
means for accessing the data.

c) This model represents the Shared Repository Pattern,

which means that it uses a database to centrally store
the data of mulitple system components.

d) The problem of the pattern represented in the above model is that performance and scalibilty issues might arise
as the system becomes more comples and/or the number of transactions increases.

Answers: c) , d)

Question 6

Based on the depicted model, which of the following statements

are correct?

a) Part C of the model corresponds to the Data Access layer;

however, the Datastore should not be directly connected to the
Controllers.

b) Part B of the model corresponds to the Domain Layer

because it contais the Controllers, which directlya ccess the

Datastore.

c) The above model is an incorrect combination of the Model-

View-Controller pattern and the Layers pattern because the Domain-Specific Logic shold be on a different layer than
the USer Interface.

d) The above model is an example of the Model-View-Controller pattern in which the “view” is in Part A, the
“Controller” in part B and the “model” in Part C.

Answers: a) , c)

Question 7

Read the following three statements about concepts found in Domain-Driven Design. Explain briefly why they are
correct or incorrect.

Statement 1: The vocabulary of the “ubiquitous language” includes names of classes and prominent operations.

TRUE. This language is used in the implementation process so that the implementation and comain concept match
bevause this language is based on the model and it is a unified language for all the stakeholders to connect all the
attitudes of the team with the software. It includes terms to discuss rules that have been made explicit in the model.

Statement 2: The code and the “ubiquitous language” expless different, mutually exclusive aspects of the same
model.

88
FALSE. The model should use the language to express a common understanding among each stakeholder so they are
in the same line with everything. Such as the code, and uniquitous language expless the same meaning.

Statement 3: Domain-Driven Design involves the creation of different domain models by the various stakeholder
groups, which are made compatible with each other by using a common “ubiquitous language”

FALSE . It has to be just one model, but iterated until there is a useful model to generate good development by
feedback coming from team members to match one language.

Question 8

Below you see a typical layered architecture. Assign

the components to the correct position and label the
individual layers.

Question 9

Name, in one sentence each, advantage and disadvantage of layered architectures:

Answer:

Advantages: Reuse of layers. If an individual layer embodies a well-defined abstraction and has a well-defined and
documented interface, the layer can be reused in multiple contexts.

You can understand a single layer as a coherent whole without knowing much about the other layers works. You can
substitute layers with alternative implementations of the same basic services.

Layers make good places for standardization. Once you have a layer built, you can use it for many higher-level
services.

Minimize dependencies.

Coupling between layers is reduced, making it easy to partially change the system (e.g. when migrating to a new
database, only the database connector would have to be changed, instead of changing all instances of code that load
data directly from the database).

Each layer is clearly separated, we know what part of the operation takes place in a given layer, so layers can be
interchanged, if they provide the same functionality, making refactoring and standardization easier.

Disadvantages: Layers encapsulate some, but not all, things well.

Every additional layer introduces coupling overhead which reduces performance, which may impede user
experience.

Changes in the layers might need to be reflected in other layers as well to retain functionality, plus too many layers
can hurt performance as the layers need to communicate between each other.

Question 10
89
Consider the following partial design description of a flight booking system (pdf):

a. Use Domain-Drive Design (DDD) to model the described situation in a detailed UML class diagram. Approapriately
use the DDD building blocks presented in the lecture.

b. For each of the modeled classes indicate (e.g. use stereotypes) whether they are one or more of the following
DDD building blocks: entity, value object, and/or aggregate root.

c. Indicate what classes belong to an aggregate by drawing a boundary around each aggregate.

Answer the tasks by uploading a UML class diagram (constructed and annotated as described by Task 1) and entering
further task-specific solutions below.

All classes are in the same aggregate

Question 12

90
For one of the aggregrate roots indicated in your UML class diagrams give in 1-2 sentences of a consistency rule that
it is suppose to enforce.

AggregateRoot: Passenger

Consistency Rules: A passenger cannot be booked on two flights at the same time

Aggregate Root: Ticket

Consistency Rule: Every Booking (except the first booking) in the ticket’s itinery must be connected to another
booking by arriving at the airport from which the next Booking’s flight departs.

Question 13

An operation ‘notifyAvailableSeats()’ should be added to obtain a count of all seats of a flight that are not booked
yet. Where would you add this operation? Choose one of the alternatives below and also describe in 1-2 sentences
how the operation is carried out:

a. Introduce a new service,

b. Introduce a new repository,

c. Introduce a new factory or add the operation to an existing class that is stated in the description

Answer task 3: add the operation to an existing class

The operation would need to return the seats that are available for booking. A factory would therefore not be a
sensible choice (we are not creating new objects). In DDD a repository should return only Aggregate Roots, which a
seat is not. The operation is not a significant change and therefore not the responsibility of a service either. Instead,
the operation should be added to the class ‘Flight’. The class would query all booking associated with it and compare
it to all seats that are on the plane which conducts the flight. The difference of these two queries would be the
output of the function.

Question 14

A domain operation ‘notifyDelayedFlights()’ should be added to allow notification of all passengers affected by a
delayed flight. Where would you add this operation? Choose one of the alternatives below and also describe in 1-2
sentences how the operation is carried out:

a. Introduce a new service,

b. Introduce a new repository,

c. Introduce a new factory or add the operation to an existing class that is stated in the description

Answer a: introduce a new service.

Again, a repository does not make sense, because no data is retrieved. A factory does not make sense either,
because the focus of the operation is not on complex creation logic. The operation is potentially too complex to be
conducted by a domain object (making calls to the infastructure layer to send out emails). Therefore, a service would
be the component of choice.

The service would take a flight number as input and iterate over all passengers, creating a message object and calling
the infrastructure layer to send the passengers an email.

Question 15

Fill in the correct term describing the dependencies between related decisions:

Decision for using Layers decomposes into decisions for internal layer structure.

91
Decision for using Middleware is refined by decision for using Apache CXF as Middleware.

Decision for using a Middleware forces decision for using a technology such as Apache CXF as Middleware.

Decision for using MVC is incompatible with using Smart UI* anti-pattern.

Decision for using a Transaction Script pattern is incompatible with the decision to use a Domain Model that
incorporates both behavior and data.

Decision for using a Smart UI} anti-pattern prunes earlier decisoon for using MVC.

*Smart UI: A Smart UI is what you get when your GUI has no separation of concerns. That is, when the user interface
and business logic are all mixed together.

Question 16

Name, in one sentence each, an advantage and a disadvantage of layered architectures.

Answer:

Advantage: It is possible to minimize the dependencies of different system parts.

Disadvantage: Performance issues may arise by introducing more layers.

92
 [Link] Exams from Other Universities
When would you use the anticorruption layers pattern?
a) to create domain independent context maps
b) to create domain context maps that interact with legacy systems
c) to create highly intersecting domain context maps
Answer: b)
When would you use the customer supplier pattern?
A) to create domain independent context maps
B) to create domain context maps that interact with legacy systems
C) to create highly intersecting domain context maps
Answer: C)
What is true about domain services?
A) the operations performed by a domain service are typically stateful
B) the operations performed by a domain service are typically comprehensive and span more than one object in the
domain
C) a domain service is usually persisted in the application backing data store
Answer: B)
What is the role of the presentation layer in model driven design paradigm?
A) implements entities persistence, and layers communication
B) encapsulates the core of the business logic
C) renders output to the user and gathers user gestures
D) harmonize and monitors the application activities and its progress
Answer: C)
When would you use the shared kernel pattern?
A) to create domain independent context maps
B) to create domain context maps that interact with legacy systems
C) to create highly intersecting domain context maps
Which domain design pattern handles object creation and storage?
A) aggregate design pattern
B) factory design pattern
C) repository design pattern
Answer: B), C)

Which design pattern you would use to enforce the domain constraints and ensure data integrity?
A) value object
B) aggregate
C) entity
D) repository
93
Answer: B)
What is the role of the Domain layer in model driven design paradigm?
A) harmonize and monitors the application activities and its progress
B) renders output to the user and gathers user gestures
C) encapsulates the core of the business logic
D) implements entities persistence, and layers communication
Which of the following are considered domain driven design patterns?
A) aggregates
B) layered architecture
C) model view controller (MVC)
D) Data Access Object (DAO)
Answer: A), B)
Which design pattern you would use to encapsulate the logic of retrieving the object references from the backing
enterprise data store?
A) value object
B) aggregate
C) entity
D) repository
Answer: D)
How would you implement a bank account object?
A) as transfer object
B) as a value object
C) as an entity
Answer: C)
What are the differences between entities and value objects?
A) entities are immutable objects while value objects are mutable objects
B) an entity has a unique identity while a value object doesn’t
C) sharing value object is thread safe as it is immutable
D) sharing an entity is thread safe as it has a unique identity
Answer: B), C)
When would you use the separate ways pattern?
A) to create domain independent context maps
B) to create domain context maps that interact with legacy systems
C) to create highly intersecting domain context maps
Answer: A)
Which design pattern you would use to create domain context maps that interact with legacy systems?
A) open host services pattern
B) anticorruption layers pattern

94
C) separate ways pattern
D) shared kernel pattern
E) customer supplier pattern
Answer: B)
Question 16
What is the most suitable programming language concept for implementing the model of Domain Driven Design
paradigm?
A) Procedural languages such as C, Pascal
B) Object-oriented programming such as Java, C++
C) Aspect oriented programming such as AspectJ
Answer: B)
How should you implement an Entity?
A) mutable object
B) immutable object
C) both are correct
Answer: A)
What is the role of the Infrastructure layer in model driven design paradigm?
A) encapsulates the core of the business logic
B) implements entities persistence, and layers communication
C) renders output to the user and gathers user gestures
D) harmonize and monitors the application activities and its progress
Answer: B)
Which design pattern you would use to encapsulate the process of complex object creation?
A) value object
B) factory
C) aggregate
D) repository
E) entity
Answer: B)
A bundle of related objects which are treated from the client prescriptive as a single unit exposing a root object.
A) value object
B) aggregate
C) entity
D) repository
Answer: B)
Which design pattern you would use to create domain context maps when the intersection between domain
contexts is high?
A) open host services pattern
B) anticorruption layers pattern
95
C) separate ways pattern
D) shared kernel pattern
E) customer-supplier pattern
Answer: D), possible E)
For an e-Shop web application, the customer will provide his personal information for shipment of the ordered
products. You would like to attach residence, invoice, delivery addresses to a person object. how would you
implement the address object?
A) as an entity
B) as a value object
C) as a transfer object
Answer: B)
How should you implement a value object?
A) mutable object
B) immutable object
C) both are correct
Answer: B)
Which domain design pattern you would use to state object ownership and boundaries?
A) aggregate design pattern
B) factory design pattern
C) repository design pattern
Answer: A)
When would you use the open host services pattern?
A) to create domain independent context maps
B) to create domain context maps that interact with legacy systems
C) to create highly intersecting domain context maps
Answer: B)
which design pattern you would use to create independent domain context maps?
A) open host services pattern
B) anticorruption layers pattern
C) separate ways pattern
D) shared kernel pattern
E) customer supplier pattern
Answer: C)

96
 [Link] (HedgeDoc)
Value Object
- An Object that describes some characteristic or attribute but carries no concept of identity.

A VALUE OBJECT can be an assemblage of other objects.

VALUE OBJECTS can even reference ENTITIES.

VALUE OBJECTS are instantiated to represent elements of the design that we care about only for what they are, not
who or which they are.

VALUE OBJECTS are often passed as parameters in messages between objects. They are frequently transient, created
for an operation and then discarded. VALUE OBJECTS are used as attributes of ENTITIES (and other VALUES). A
person may be modeled as an ENTITY with an identity, but that person’s name is a VALUE.

Two Values objects are equal, if and only if all their attributes are equal.

To protect against two objects having a common property such as Name that points to the same name instance, in
order for an object to be shared safely, it must be immutable: it cannot be changed except by full replacement.

Entity Object
An object that is defined by a thread of continuity and identity.

When there is no true unique key made up of the attributes of an object, another common solution

is to attach to each instance a symbol (such as a number or a string) that is unique within the class.

Once this ID symbol is created and stored as an attribute of the ENTITY, it is designated immutable.

Zachman-Framework
A framework for enterprise architecture, which provides a formal and highly structured way of viewing and defining
an enterprise.

Reference Model for Open Distributed Processing (RMODP)

A reference model, which provides a coordinating framework for the standardization of open distributed processing
(ODP)

4+1 View-Model
A view model for describing the architecture of software-intensive systems, based on the use of multiple, concurrent
views

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. Recognize that a change in the UBIQUITOUS LANGUAGE is a change to the model.

A bounded context
is simply the boundary within a domain where a particular domain model applies.

Domain-drive Design
is an approach to software development for complex needs by connecting the implementation to an evolving model.

Transaction Script
Organizes business logic by procedures where each procedure handles a single request from the presentation.

97
Most business applications can be thought of as a series of transactions. A transaction may view some information as
organized in a particular way, another will make changes to it. Each interaction between a client system and a server
system contains a certain amount of logic. In some cases this can be as simple as displaying information in the
database. In others it may involve many steps of validations and calculations.

A Transaction Script organizes all this logic primarily as a single procedure, making calls directly to the database or
through a thin database wrapper. Each transaction will have its own Transaction Script, although common subtasks
can be broken into subprocedures.

Applicability
Use the Transaction Script pattern when the application has only a small amount of logic and that logic won’t be
extended in the future.

Consequences
As the business logic gets more complicated, it gets progressively harder to keep the transaction script in a well-
designed state.

Code duplication between transaction scripts can occur.

Normally not easy to refactor transactions script to other domain logic patterns.

Model View Controler

Splits user interface interaction into three distinct roles.

Aggregate
An AGGREGATE is a cluster of associated objects that we treat as a unit for the purpose of data changes. – Evans,
2003.

Aggregate is a pattern, that Evans describes in the lifecycle management chapter of the blue book.

The motivation is that we often have two or more domain entities that must always agree with each other in some
way. That will normally mean that we want to save them together (otherwise, a badly timed failure could leave us in
a state where the entities are not consistent with each other), and will normally mean that we want to have both
entities available in any case where we might change one (because we’ll need to make sure that change is consistent
with the other).

are aggregate roots connected with rules?

Yes, aggregate roots are connected with rules in Domain-Driven Design (DDD). Aggregate roots are entities that act
as the primary point of interaction for a group of related objects known as an aggregate. Aggregates are collections
of objects that are treated as a single unit, with the aggregate root serving as the entry point to the aggregate.

DDD emphasizes the use of business rules to guide the design of domain models. These business rules can be
enforced within an aggregate through the aggregate root. The aggregate root is responsible for maintaining the
consistency and integrity of the objects within the aggregate, and it ensures that all changes to the aggregate adhere
to the defined business rules.

Therefore, the aggregate root plays a critical role in connecting the business rules with the objects within the
aggregate. The rules can be enforced through the methods and operations provided by the aggregate root, which
encapsulates the logic needed to maintain the consistency and integrity of the aggregate.

Most Common Layers:

Taking from Martin Fowler’s patterns of enterprise design, the most common layers are:

Presentation - these are views, presentation templates which generate the interaction interface for your application
(I am using interaction in case your application is accessed by other systems through web services or RMI so may not
be a user interface). This also includes controllers which decide how actions will be executed and how.
98
Domain - this is where your business rules and logic resides, your domain models are defined etc

Data Source - this is the data mapping layer (ORM) and data source (database, file system etc)

How do you draw the boundaries between the three layers:

Do not put presentation specific logic within your models or domain objects

Do not put logic within your pages and controllers, i.e., logic to save objects to the database, create database
connections etc, which will make your presentation layer brittle and difficult to test

Use an ORM which enables you to decouple your datasource access and actions from the model

Follow the thin controller - fat model paradigm, controllers are for controlling the process of execution not carrying
it out, more at [Link] and
[Link] model, view and controller,

[Link] Questions

4+1 View Model

what is a 4+1 View model?
The 4+1 View Model is a software architecture model that was proposed by Philippe Kruchten in 1995. It is used to
describe the architecture of a software-intensive system, such as a software application or a software product line.

The model consists of five concurrent views, each of which represents a different perspective on the system:

Logical View: This view represents the functionality that the system provides to its users. It describes the system's
functionality in terms of the components, their interactions, and the services that they provide.

Development View: This view represents the organization of the software components that are used to implement
the system. It describes the software components, their relationships, and the development environment.

Process View: This view represents the concurrency and synchronization aspects of the system. It describes the
system's runtime behavior in terms of the processes, threads, and synchronization mechanisms.

Physical View: This view represents the physical distribution of the system across different hardware components. It
describes the deployment of the software components and their interactions with the hardware.

Scenarios View: This view represents the system's behavior in response to different usage scenarios. It describes how
the system behaves in response to different inputs and events.

The "+1" in the 4+1 View Model refers to the use of scenarios as a unifying thread that connects the other four views
together. The scenarios view helps to ensure that the system is designed to meet the needs of its users and
stakeholders, and that the other views are consistent with each other.

what is Domain-Driven Design?

Domain-Driven Design (DDD) is an approach to software development that focuses on the business domain and its
underlying complexity. The main goal of DDD is to create software that is closely aligned with the business domain
and the business needs, rather than focusing primarily on technical considerations.

In DDD, the business domain is modeled using a rich, expressive vocabulary that is shared by the development team
and the business stakeholders. This vocabulary is used to create a shared understanding of the business domain, its
concepts, and its relationships. This understanding is then translated into a software model that is designed to
closely mirror the business domain.
99
DDD also emphasizes the use of bounded contexts, which are logical boundaries around specific areas of the
business domain. Each bounded context is responsible for a specific set of business concepts, and has its own
distinct model. Bounded contexts help to manage the complexity of large-scale software systems, by breaking them
down into smaller, more manageable parts.

DDD also encourages the use of ubiquitous language, which is a common vocabulary used by the development team
and the business stakeholders to communicate about the system. This language helps to bridge the gap between the
technical and business domains, and ensures that everyone has a shared understanding of the system's concepts
and requirements.

Overall, DDD is a powerful approach to software development that emphasizes the importance of understanding and
modeling the business domain, and creating software that is closely aligned with the business needs. By doing so,
DDD can help to create software systems that are more effective, maintainable, and adaptable to changing business
requirements.

Domain-Driven Design (DDD) and the 4+1 View Model are two distinct approaches
to software design and development, but they can be used together.

The 4+1 View Model provides a way to view a software system from multiple perspectives, including the logical,
development, process, physical, and scenarios views. This approach helps to ensure that all aspects of the system are
considered and designed appropriately.

DDD, on the other hand, is focused on modeling the business domain and its underlying complexity, using a shared
vocabulary and a domain-specific language. DDD emphasizes the importance of understanding the business domain
and its requirements, and creating software that is closely aligned with those requirements.

The 4+1 View Model can be used as a way to organize and describe the different views of a software system, while
DDD can be used to create a domain model that is closely aligned with the business domain. By combining these two
approaches, developers can create software that is well-designed, well-organized, and closely aligned with the needs
of the business.

Overall, while the 4+1 View Model and DDD are not directly connected, they can be used together to create effective
software systems that are closely aligned with the needs of the business.

what are the building blocks of domain driven design?

Domain-Driven Design (DDD) is based on a set of building blocks that are used to model the business domain and
create software systems that are closely aligned with the business needs. The main building blocks of DDD are:

Entities: These are objects that have a unique identity and a lifespan that extends beyond a single transaction.
Entities represent concepts in the business domain that are important and have a long lifespan, such as customers,
orders, or products.

Value Objects: These are objects that have no unique identity, but are defined by their attributes. Value objects
represent concepts in the business domain that are important, but do not have a long lifespan, such as a price or a
date range.

Aggregates: These are clusters of related objects that are treated as a single unit. Aggregates define consistency
boundaries within which changes must be made atomically. Aggregates are often composed of entities and value
objects.

Services: These are operations or functions that perform specific tasks or calculations in the business domain.
Services are often used to coordinate multiple aggregates and ensure consistency between them.

100
Repositories: These are abstractions that provide a way to store and retrieve aggregates from a persistent storage.
Repositories provide a clean separation between the application and the infrastructure, and help to ensure that the
domain model is not polluted with persistence concerns.

Domain Events: These are messages or notifications that are emitted by the domain model when significant changes
occur. Domain events can be used to trigger actions or updates in other parts of the system, and help to ensure that
the system remains consistent.

Overall, these building blocks provide a set of concepts and tools that can be used to model the business domain and
create software systems that are closely aligned with the business needs. By using these building blocks, developers
can create software that is easier to understand, maintain, and adapt to changing business requirements.

what is DAO?
DAO stands for "Data Access Object". It is a design
pattern that is commonly used in software
development to separate the business logic of an
application from the persistence logic (i.e., how the
application interacts with a database or other data storage system).

In a DAO pattern, a data access object acts as an intermediary between the application and the data source. The
DAO is responsible for handling all of the interactions with the data source, such as retrieving data, inserting data,
and updating data.

By separating the persistence logic from the business logic, developers can create a more modular and maintainable
application. The DAO pattern also helps to ensure that the application is scalable and can easily be adapted to
different data sources.

101
In Java, the DAO pattern is often implemented using interfaces and classes. The interface defines the methods that
will be used to interact with the data source, and the implementing class provides the actual implementation of
those methods.

Inject @autowired
"Dependency Injection" (DI) is a technique that is commonly used in software development to help manage the
dependencies between different components of an application. In Spring Boot, dependency injection is used
extensively to manage the relationships between Spring beans.
Dependency injection
Dependency injection in Spring Boot means that the framework is responsible for creating and managing the objects
(or beans) that your application needs. Rather than creating objects directly in your code, you define them as Spring
beans and let Spring handle the creation and configuration of those beans.

To define a bean in Spring Boot, you can use the @Component annotation or one of its subtypes (@Service,
@Repository, etc.). You can also use the @Autowired annotation to inject a dependency into a Spring bean.

For example, suppose you have a UserService that depends on a UserRepository to access user data. You can define
the UserService and UserRepository as Spring beans like this:

java
Copy code
@Repository
public class UserRepository {
// Implementation details...
}

@Service
public class UserService {

private final UserRepository userRepository;

@Autowired
public UserService(UserRepository userRepository) {
[Link] = userRepository;
}

// Other methods...
}
In this example, the UserRepository is defined as a Spring bean using the @Repository annotation. The UserService is
also defined as a Spring bean using the @Service annotation. The @Autowired annotation is used to inject the
UserRepository dependency into the UserService constructor.

By using dependency injection in this way, Spring Boot manages the lifecycle of the beans and ensures that the
dependencies are satisfied correctly. This helps to create a more modular and maintainable application.

In Spring Boot, a "bean" is simply an object that is managed by the Spring framework. Spring beans are defined in
the Spring container and can be configured to be created and initialized at different stages of the application
lifecycle.

Spring beans can be thought of as the building blocks of a Spring application. They can be used to represent anything
from a simple value object to a complex business object. Beans can be injected into other beans, allowing for the
creation of complex object graphs that represent the various components of the application.

102
Spring beans are defined using annotations or XML configuration files. Annotations such as @Component, @Service,
@Controller, and @Repository are used to mark classes as Spring beans. These annotations help the Spring
framework to identify the beans and manage their lifecycle.

@Qualifier
what is @qualifier?
In Spring Boot, @Qualifier is an annotation that can be used to disambiguate beans when there are multiple beans of
the same type.

When there are multiple beans of the same type in the Spring container, you can use @Qualifier along with
@Autowired to specify which bean should be injected. This is useful in scenarios where you want to inject a specific
implementation of an interface or when you have multiple beans with the same interface.

For example, suppose you have two beans that implement the same interface:

java
Copy code
public interface MessageService {
String getMessage();
}

@Component("welcomeMessageService")
public class WelcomeMessageService implements MessageService {

@Override
public String getMessage() {
return "Welcome to the application!";
}

@Component("goodbyeMessageService")
public class GoodbyeMessageService implements MessageService {

@Override
public String getMessage() {
return "Goodbye!";
}

}
In this example, we have two implementations of the MessageService interface: WelcomeMessageService and
GoodbyeMessageService. We have used the @Component annotation to mark these classes as Spring beans and
provided a name for each bean using the value attribute.

To inject the WelcomeMessageService bean, we can use @Autowired and @Qualifier like this:

java
Copy code
@Service
public class MyService {

private final MessageService messageService;

@Autowired

103
 public MyService(@Qualifier("welcomeMessageService") MessageService messageService) {
[Link] = messageService;
}

// Other methods...

}
In this example, the @Qualifier annotation is used to specify that we want the welcomeMessageService bean to be
injected into the MyService constructor.

By using @Qualifier in combination with @Autowired, we can select the desired bean when there are multiple beans
of the same type in the Spring container.
Dependency Injection!!

@JsonProperty makes the properties to jsons in database

@RequestMapping (“api…”)
To create first endpoint with spring

In general, annotations in Spring are used to provide metadata about classes, methods, and fields to
the Spring framework, which can then use that information to configure the application at runtime. Annotations can
be used to control things like bean creation, dependency injection, database mapping, and more.

Here are some examples of when you might need annotations in a Spring application:

To mark a class as a Spring-managed bean: You can use annotations like @Component, @Service, or @Repository to
mark a class as a bean that should be managed by Spring.

To configure dependency injection: You can use annotations like @Autowired, @Qualifier, or @Value to inject
dependencies into your Spring-managed beans.

To configure web requests: You can use annotations like @RequestMapping, @GetMapping, @PostMapping, etc. to
map HTTP requests to controller methods.

To configure database access: You can use annotations like @Entity, @Table, @Column, etc. to map Java classes to
database tables and columns.

To enable specific features in Spring: You can use annotations like @EnableCaching, @EnableAsync,
@EnableScheduling, etc. to enable specific features in Spring.
StundeRepository extends MongoRepository
findAll, insert, findbyID, ….

what is docker image?

A Docker image is a lightweight, standalone, and executable package that contains everything needed to run an
application, including the application code, libraries, dependencies, system tools, and runtime. It is created by
building a Docker container, which is a standardized unit of software that packages up the application and all its
dependencies. The image can then be easily deployed and run on any machine that has Docker installed, providing a
consistent environment and ensuring that the application runs the same way regardless of the hosting environment.

layered architecture
For example, you can have a layered architecture with the following layers:

Presentation layer/UI: This layer handles the user interface and user input/output. It consists of components such as
controllers, views, and templates.
104
Application layer: This layer contains the application logic and use cases of the system. It consists of components
such as services, use case controllers, and application domain objects.

Domain layer: This layer contains the domain entities, value objects, and business rules of the system. It consists of
components such as entities, value objects, domain services, and domain events.

Infrastructure layer: This layer provides the technical infrastructure and support for the other layers. It consists of
components such as database access, messaging, logging, and external service integration.

Each layer provides a different level of abstraction and functionality, and communicates with the adjacent layers
through well-defined interfaces. The layered architecture can help you achieve separation of concerns,
modularization, and flexibility in your system.

What is Ubiquitous Language?

In software engineering, Ubiquitous Language refers to a shared language or vocabulary used by all members of a
development team, including developers, domain experts, and business stakeholders. It is a language that is
common and understood by all parties involved in a software development project, regardless of their technical or
non-technical backgrounds.

The concept of Ubiquitous Language was introduced by Eric Evans in his book "Domain-Driven Design." It
emphasizes the importance of creating a language that is understood by everyone involved in a project to ensure
that there is a common understanding of the domain, requirements, and specifications. The goal is to eliminate
misunderstandings and reduce the gap between the domain experts and technical team members.

By adopting a Ubiquitous Language, the development team can create a shared understanding of the project
requirements and domain, which can help to create more effective communication and collaboration, reduce errors,
and speed up development time. This approach can lead to more successful software development projects, as it
promotes a shared understanding and a sense of ownership among all stakeholders involved in the project.

what is Hibernate/ JPA lazy loading?

Hibernate and Java Persistence API (JPA) are popular Object-Relational Mapping (ORM) frameworks used in Java-
based applications. Lazy loading is a feature provided by these frameworks that allows entities to be loaded from the
database only when they are needed.

Lazy loading is a technique used to defer the loading of data until it is actually required. In Hibernate/JPA, when an
entity is loaded, it may have associated relationships with other entities that are also mapped as fields in the entity
class. By default, these related entities are not loaded from the database until they are actually accessed in the code.
This is known as lazy loading.

For example, suppose you have an entity called Customer that has a one-to-many relationship with Order entities.
When you load a Customer entity from the database, Hibernate/JPA will not load the associated Order entities by
default. Instead, it will create a placeholder or proxy for the Order entities that can be used to fetch the actual data
from the database when needed. If you later access the orders field of the Customer entity in your code,
Hibernate/JPA will automatically fetch the associated Order entities from the database and populate the orders field.

Lazy loading can help to improve performance and reduce the amount of unnecessary data loaded from the
database. However, it can also lead to issues such as the N+1 problem, where multiple SQL queries are executed to
fetch related entities, which can cause performance issues in certain scenarios. It is important to use lazy loading
judiciously and consider the specific requirements and performance characteristics of the application.

105
What is Shared Kernel?
shared Kernel is an integration pattern used in Domain-Driven Design (DDD) to establish a shared understanding of a
specific part of the domain model between two or more Bounded Contexts. In this pattern, two Bounded Contexts
agree to share the same codebase or a portion of it to ensure consistency in the domain model's interpretation.

A Shared Kernel typically includes the most critical and stable parts of the domain model that are critical to both
Bounded Contexts. These parts are defined and agreed upon by the teams responsible for each Bounded Context.
The Shared Kernel can be implemented as a shared library or module containing the shared code and domain model.

The Shared Kernel pattern is used when multiple Bounded Contexts need to interact with each other and share a
part of their domain model. It can be useful when there is a significant overlap between two Bounded Contexts, and
keeping them completely isolated would result in duplicating code or creating inconsistencies. Sharing a kernel helps
ensure that the domain model is consistent and that changes to it are coordinated between Bounded Contexts.

However, this pattern should be used with caution, as it can create tight coupling between Bounded Contexts,
making it harder to evolve and maintain them independently. Therefore, it is crucial to carefully consider the scope
of the Shared Kernel and establish clear guidelines for its use.

What is Partnership?
Partnership is an Integration Pattern in Domain-Driven Design where two Bounded Contexts agree to share parts of
their Domain Model. This involves creating a separate Bounded Context, called the Partnership Context, to define
the shared concepts, which are usually kept to a minimum. The idea is to allow the two Bounded Contexts to
collaborate more easily without needing to know all the details of each other's Domain Model. However, this pattern
should be used with caution, as it can lead to tight coupling between the two Bounded Contexts and make it difficult
to maintain each Context's autonomy.

What is the difference between Shared Kernel and Partnership?

The Partnership pattern is similar to the Shared Kernel pattern in that it involves two or more bounded contexts
collaborating with each other. However, the Partnership pattern is typically used when the collaboration between
the bounded contexts is more complex than simply sharing a common subset of the domain model.

In the Partnership pattern, the teams responsible for each bounded context work together closely to define a joint
solution that satisfies the requirements of both contexts. This may involve defining a common API, exchanging data
in a specific format, or sharing infrastructure components.

Unlike the Shared Kernel pattern, which involves a shared subset of the domain model that is used by all
collaborating bounded contexts, the Partnership pattern allows each bounded context to maintain its own distinct
domain model.

What is a Conformist Relation?

In Domain-Driven Design, a Conformist relationship is a type of relationship between Bounded Contexts where one
context adheres to the API and language of another context, even if it does not need to use all of its functionality.
This relationship is established when a context chooses to use a portion of the public interface of another context as
if it were part of its own internal model, without adding any new requirements or behaviors to that interface. This
way, the conformist context becomes dependent on the other context, and must adapt to any changes made to it.

A Conformist relationship can be useful when a Bounded Context needs to reuse some of the functionality of
another context, but does not need the full breadth of its capabilities. It can also simplify integration between
contexts, as the conformist context can use the same language and concepts as the provider context, which helps to
reduce misunderstandings and communication overhead. However, it also means that any changes to the provider
context can potentially have an impact on the conformist context, and care should be taken to manage this
dependency.

106
What is an Anti Corruption Layer?
An Anti Corruption Layer (ACL) is a pattern used in Domain-Driven Design (DDD) to isolate and protect a domain
model from external systems or legacy systems that do not conform to the domain model's design and coding
standards.

The ACL serves as a shield between the domain model and the external systems by providing a set of interfaces and
adapters that convert data and communication protocols from the external system into a format that the domain
model can understand. The ACL ensures that the external system's data is translated into the domain model's
language and standards, preserving the integrity of the domain model.

In other words, the ACL helps prevent the "corruption" of the domain model by external systems or legacy systems
that do not adhere to its design principles. By providing a layer of abstraction, the ACL allows the domain model to
evolve independently of external systems, reducing the risk of contamination or unintended side effects.

How do I design a domain model?

There are basically six building blocks available for you to design a domain model: Entity, Value Object, Aggregate,
Repository, Factory and Service. The basic steps of getting started are:

1) Figuring out what entities and value objects are

2) Defining an aggregate to represent a group of related entities and value objects

3) Choosing an entity to be the root entity of the aggregate

4) Defining behaviours of these entities based on domain knowledge (ubiquities language)

5) Adding APIs in the root entity to ensure all child entities life cycle are managed via root entity.

6) Designing factory and repository for the root entity to manage the life cycle of the aggregate.

7) You will find that some business behaviours are belong to more than one entity, then, this is a time you need to
create a service to coordinate these entities to fulfill the business behaviour.

What is a domain model?

Domain model shows you how a domain problem should be solved. domain model depicts the relationships and
interactions between domain entities and value objects based on domain knowledges described by domain expert or
users.

Video: What is Software Architecture?

107
Linux, demons:

Little server processes that do small jobs

If one crashes, it still keeps going

BDUF: Big design upfront

108
109