Script Savvy

Pattern Software Design - Individual Assignment 1 Week 2

Individual Assignment Pattern Software Design

---

Theory Questions

1. What is meant by software complexity?

Software complexity serves as an indicator of intricacy in understanding, maintaining, modifying, and reusing software. If the complexity value is high, developers will encounter difficulties in understanding the software during maintenance or when implementing changes. Therefore, monitoring software complexity is necessary to determine the quality and reliability of the software using software metrics.

Complexity is an indicator of interrelationships within a project, program, or portfolio that affect how these relationships will be managed and the skills required to manage them.

 

2. How does DDD handle the challenge of understanding the problem domain and creating maintainable solutions useful for solving the problems within it? Does it achieve this by utilizing a number of strategic and tactical patterns, whether they are DDD Strategic Patterns?

DDD's strategic patterns offer a problem domain and shape the architecture of an application. DDD strategic patterns:

• Filtering Problem Domains to Reveal What's Important: The core domain is the driving force behind the product being developed. Discovering the core domain helps the team understand why they are producing software and what it means for the software to be successful for the business.

• Making Models to Solve Domain Problems: Software domain models are built for each subdomain to address domain problems. These models are not real-life models but rather abstractions built to meet business use case requirements while maintaining business domain rules and logic.

• Using Shared Language to Enable Collaboration: Models are built through collaboration between domain experts and development teams. Communication is achieved using a language known as ubiquitous language (UL) to efficiently and effectively connect software models to conceptual analysis models.

• Separating Models from Ambiguity and Corruption: Larger models can be broken down into smaller models and defined in separate limited contexts where there is ambiguity in terminology or where multiple teams work to reduce complexity. Models are isolated from infrastructure code to avoid unintended complexity from merging technical and business concepts.

• Understanding Context Relationships: DDD understands the need to ensure that teams and businesses clearly understand how separate models and contexts work together to solve domain problems spread across subdomains. Context maps help understand the bigger picture. They enable teams to understand what models exist, what they are responsible for, and where their boundaries lie.

 

3. Explain the differences between a system built with structured analysis and design (SSAD) and a system built with object-oriented analysis and design (OOAD)?

Structured Analysis and Design (SSAD) is the activity of transforming an analysis result into a plan for implementation (detailed design).

Advantages

• Milestones are clearly shown, making project management easier.

• SSAD is a visual approach, making it easily understandable by users or programmers.

• The use of graphical analysis and tools such as DFD makes SSAD suitable for use.

• SSAD is a method known generally across various industries.

Disadvantages

• SSAD mainly focuses on processes, thus neglecting non-functional requirements.

• There is little direct management associated with SSAD.

• The basic principles of SSAD are non-iterative development (waterfall), but requirements will change in each process.

Object-Oriented Analysis and Design (OOAD) is a new technique or approach to viewing problems and systems (software systems, information systems, or other systems).

Advantages

• Compared to the SSAD method, OOAD is easier to use in system development.

• Compared to SSAD, development time, organizational level, robustness, and reuse of program code are higher than the OOAD method (Sommerville, 2000).

• There is no separation between the design and analysis phases, thus enhancing communication between users and developers from the beginning to the end of system development.

• Analysts and programmers are not limited by system implementation constraints, so designs can be formulated that can be confirmed with various execution environments.

Disadvantages

• In the initial OOAD design, the system may be very simple.

• OOAD focuses more on coding compared to SSAD.

• OOAD does not emphasize team performance as much as SSAD.

 

4. What is meant by design pattern? and what are the benefits gained in implementing design patterns?

A design pattern is a method to help solve common problems or patterns in software development.

The advantages include speeding up software development because the patterns described in Design Pattern are proven paradigms. By using these Design Patterns, it can help solve a problem, also making communication more effective, and programmers can reuse projects more easily.

 

5. What are the following called:

• Bounded Context

  It is an approach that separates a large model into small contexts explicitly and the relationship between the two. With Bounded Context, there is no need to worry about differences in vocabulary or differences in scientific concepts used in software development.

• Ubiquitous Language

  It is a language chosen/created by everyone involved in the project such as the Development Team and domain experts will work together to determine the language that will be used in the program. And in the end, domain experts can also understand the code written by the development team.

• Core domain

  It is the most important subdomain in a business and can make a difference from others. If there is no core domain then a business cannot succeed.

• Domain expert

  It is an expert who has specialized knowledge, opinions, experience, and methods, as well as the ability to apply that expertise to solve problems.

• Business driven

  It is a methodology for developing IT solutions that directly meet business requirements.

 

Case Study

Write an article about domain design patterns. The article consists of 1 A4 page with "single" line spacing. References can be used (journals, proceedings, books, blogs).

Domain-Driven Design (DDD) is an approach to software development that allows teams to effectively manage the construction and maintenance of software for complex problem domains. DDD is a development philosophy defined by Eric Evans.

In software development, there is a challenge where customers do not really know what they need. According to research published by Compustat in 2014, the software industry holds the third position in uncertainty. Regardless of the methodology or framework used, we see the problem of uncertainty from the perspective of miscommunication. DDD provides tools to avoid miscommunication between business teams and software development teams, namely Ubiquitous Language.

Ubiquitous Language is a common language within a team, created by programmers, business, product owners, and testers. Ubiquitous Language is a term coined by Eric Evans to build a common and rigid language between development teams and users.

DDD provides clear guidelines on how your objects should interact, and helps you divide your objects into the following categories:

• Value objects, which represent values that may have sub-parts (for example, a date may have a day, month, and year).

• Entities, which are objects with identity. For example, each Customer object has its own identity, so we know that two customers with the same name are not the same customer.

• Aggregate roots are objects that have other objects. This is a complex concept and works on the basis that some objects don't make sense unless they have an owner. For example, the 'Order Line' object doesn't make sense without the 'Order' being owned, so we say that Order is the aggregate root, and the Order Line object can only be manipulated through methods in the Order object.

DDD also recommends several patterns:

• Repository, a pattern for persistence (storing and retrieving your data, usually to/from a database).

• Factory, a pattern for creating objects.

• Services, a pattern for creating objects that manipulate primary domain objects without being part of the domain itself.

 

References

Evans, Eric. 2003. Domain-Driven Design: Tackling Complexity in the Heart of Software. Boston: Addison Wesley

Fowler, Martin. 2006. Ubiquitous Language. https://martinfowler.com/bliki/UbiquitousLanguage.html