Domain-driven design is an object-oriented modeling approach that integrates software system analysis and design, so a deep understanding of DDD requires a deep understanding of OOAD(Object-oriented analysis and Design).

Object-oriented Analysis and Design OOAD: Object Model

Object Model Overview

Object oriented technology is based on a very good engineering foundation, which is “development object model”, referred to as “object model”.

The object model includes the principles of abstraction, encapsulation, modularity, hierarchy, type, concurrency, and persistence. These principles are not exclusive to the object model, but the object model combines these elements in a cooperative way.

What are the benefits of using an object-oriented model?

First, using the object model helps us explore the expressiveness of object-based and object-oriented programming languages.

Secondly, the use of object model not only encourages software reuse, but also encourages design reuse.

Finally, using the object model results in a system built on a stable intermediate state that is more adaptable to change, meaning that it can evolve over time, rather than having to scrap the original design and completely redesign when major changes are made to requirements.

The object model-related methods (OOA, OOD, OOP) and elements (seven principles: Abstraction, encapsulation, modularity, hierarchy, type, concurrency, and persistence) are briefly introduced to help you understand them.

Object oriented programming OOP

What is object-oriented programming?

Object-oriented programming is an implementation approach in which programs are organized into groups of cooperating objects, each representing an instance of a class that belongs to a hierarchy formed through inheritance.

This definition has three main points:

1. Use objects as the basic logical building blocks of object-oriented programming.

2. Each object is an instance of some class.

3. Classes can be related to each other through inheritance.

A program that does not meet any of these criteria is not an object-oriented program.

Object oriented Design

So what is object-oriented design?

Object-oriented design is a design method, including the process of object-oriented decomposition and a representation, which is used to represent the logical model, physical model, static model and dynamic model of the designed system.

There are two main points in this definition:

1. Object-oriented design leads to object-oriented decomposition.

2. Object-oriented design uses different representations to express different models of logical design (class and object structure) and physical design (module and processing architecture), as well as static and dynamic characteristics of the system.

Object-oriented analysis OOA

So what is object-oriented analysis?

Object-oriented analysis is an analysis method that uses classes and objects found in the vocabulary of the problem domain to analyze requirements.

The relationship between OOA, OOD, and OOP is:

The result of object-oriented analysis can be used as the model of object-oriented design, and the structure of object-oriented design can be used as the blueprint to realize a system using object-oriented programming method.

Object model elements

The object model has seven elements, including four major elements and three minor elements.

There are four main elements of an object-oriented model that determine whether a model is object-oriented or not:

1, abstract

2, encapsulation

3. Modularization

4. Hierarchy

There are also three minor elements of an OBJECT-ORIENTED model, meaning they are useful components of an object-oriented model, but not essential:

1, type,

2, concurrent

3, durable

abstract

From the perspective of human cognition of the world, abstraction is the basic way for us to deal with complexity. Abstractions come from our perception of the similarities of a particular object, scene, or process in the real world, and our decision to focus on those similarities while ignoring the differences.

Abstract is a simple description or reference of a system, emphasizing some details or properties of the system while ignoring others. Therefore, good abstractions emphasize the details that are important to the user and suppress temporary, nonessential details.

For object models, abstractions describe the basic characteristics of an object, distinguish it from all other types of objects, and thus provide a clearly defined conceptual boundary that is relevant to the perspective of the observer.

Abstractions focus on an external view of an object, so you can separate the object’s basic behavior from its concrete implementation. The boundary between behavior and implementation is the so-called “abstract barrier”, which is achieved through the application of the principle of minimum commitment.

The principle of minimum commitment requires that an object’s interface provide only its basic behavior and nothing else.

Abstract types:

Abstract entities

Action abstract

Virtual Machine abstraction

Accidental abstract

Example of abstraction: smart speakers.

Now intelligent devices are increasingly popular, including traditional audio, but also by the Internet + to become IoT devices.

Based on the stereo

Abstract: Speakers

Important features: Sound position

Responsibility: Play sound

Abstract: Smart speakers

Important features: Sound location network

Responsibility: Collect sound playback sound connection network

encapsulation

What is encapsulation?

Encapsulation is the process of separating the elements that make up an abstract structure and behavior. The purpose of encapsulation is to separate the abstract conceptual interface from its implementation.

Encapsulation is a complementary concept to abstraction:

Abstract is concerned with the observable behavior of objects, and encapsulation is concerned with the implementation of these behaviors.

2. Encapsulation is usually achieved through information hiding. Information hiding is the process of hiding secrets that do not involve the essential characteristics of an object, usually the structure of an object and the implementation of its methods. The goal of encapsulation is that no part of a complex system should depend on the internal details of any other part.

3. Encapsulation provides clear boundaries between different abstractions, thus leading to a clear separation of concerns.

modular

What is modularity?

Modularity is the property of a system that is decomposed into a set of highly cohesive, low-coupling modules.

Splitting a program into several different components reduces its complexity to some extent. Modularity divides a program into modules that can be compiled independently but are related to other modules. High cohesion means putting logically related abstractions together; Low coupling means reducing dependencies between modules.

hierarchy

What is the hierarchy?

A hierarchy is a kind of hierarchy or ordering of abstractions.

The two most important hierarchies in a complex system are its class hierarchies (” is a kind “hierarchies, such as inheritance) and object hierarchies (” component” hierarchies, such as aggregation).

Inheritance basically defines a relationship between classes in which a class shares a structure or behavior defined in one or more classes (corresponding to single inheritance and multiple inheritance, respectively).

The “is” hierarchy describes general/specific relationships (e.g., mammal/cat), while the “components” hierarchy describes aggregate relationships.

The combination of inheritance and aggregation is powerful: aggregation allows physical grouping of logical structures, while inheritance allows these common parts to be reused in different abstractions.

type

What is a type?

A type is a class enforcement of an object, so objects of different types cannot be used interchangeably, or at least their interchangeable use is very restricted.

The concept of type matching is at the heart of the concept of type. Types are generally classified into strong and weak types.

Strongly typed languages have some important benefits:

1. Through type checking, programs can be reduced to crash in mysterious ways.

2. On most systems, the process from editing to compiling to final debugging is tedious, so early error checking is essential.

3. The declaration of the type helps to document the program and standardize the interaction between the program and the outside.

4. By declaring types, most compilers can generate more efficient object code.

5. In practice, the security that comes with strong typing often compensates for the loss of flexibility that comes with not using a typeless language, especially in large-scale programming.

In addition to strong and weak types, there are static and dynamic types.

Static typing refers to the types of all variables and expressions that are fixed at compile time and is therefore also called static or early binding. Dynamic typing means that the type of any variable or expression is not known until run time, so it is also called late binding.

Polymorphism is a situation that occurs when dynamic typing and inheritance interact. Polymorphism states that a single name or variable declaration can represent many objects of different classes that have a common superclass.

concurrent

What is concurrency?

Concurrency is a property that distinguishes active objects from inactive objects.

Sometimes we need the system to handle many different events at once, and sometimes we need to do more computations than a single processor can do. In these cases, we should consider using a group of distributed computers to achieve our goals, or use multi-tasking. This is where concurrency comes in.

persistent

In software, an object takes up a certain amount of space and exists for a certain amount of time.

Persistence is not the only problem with data life cycles.

What is enduring?

Persistence is a property of an object by which an object exists across time (for example, when the object’s creation does not exist) and space (for example, when the object’s location is moved away from the address space where it was created).

Object-oriented Analysis and Design OOAD: Classes and objects

Nature of object

The ability to recognize physical objects, such as a baby’s ability to recognize faces around him or her, comes from very early in life.

In a broad sense, an object reflects a part of something that really exists, and therefore is something that exists in time and space.

In software development, an object is an entity with state, behavior, and identifier. Objects with similar structure and behavior are defined in their common class. The terms instance and object are used interchangeably.

Object state

The state of an object includes all the attributes of the object (which are usually static) and the current value of each attribute (which is usually dynamic).

An attribute is an inherently unique feature, trait, quality, or quality that distinguishes one object from others.

Properties are usually static because such characteristics are immutable and are the fundamental nature of the object. There are exceptions, however, because in some cases the attributes of the object change.

Every object has a state, and all objects in the system encapsulate some state, and all states in the system are encapsulated by objects, and each object occupies some space in the physical world or in computer memory. Although some objects have the same properties, they do not share these Spaces.

Behavior of objects

No object is an island. Of course, an island is also an object. It is important to emphasize that objects do not exist in isolation, but interoperate with each other.

Behavior is how an object behaves and reacts in terms of state changes and messaging. In other words, the behavior of an object represents the activity visible to it. Thus, the definition of state can be improved to say that the state of an object represents the cumulative effect of its behavior.

The behavior of an object includes the sum of its operations. An operation represents a service that a class provides to its objects.

In practice, we found that a customer typically performs five operations on an object.

There are three common operations:

  • Modify operation: The operation that changes the state of an object.

  • Select operations: Operations that access the state of an object without changing the state.

  • Traversal: An operation that accesses all parts of an object in a well-defined way. Two other common operations:

  • Construct operation: The operation of creating an object and initializing its state.

  • Destructor operation: The operation that releases the state of an object and destroys the object itself.

All methods of an object together constitute its protocol. Thus, an object’s protocol defines the encapsulation of the behavior that the object is allowed to perform, and constitutes a complete static and dynamic view of the object.

Accountability means expressing a goal of the object and its place in the system. An object’s responsibility is all the services it provides for all the contracts it supports.

The identifier of the object

An identifier is an attribute of an object that distinguishes this object from all other objects.

The unique identifier of each object remains constant throughout the life of the object, even when its state changes.

Relationships between objects

A single object is very limited; objects make systems more powerful by cooperating with other objects.

There are two important relationships in object-oriented analysis and design, one is linkage and the other is aggregation.

A link is a physical or conceptual connection between two objects. One object works with other objects by linking to them.

Links represent concrete associations by which one object (a customer) requests the services of another object (a service provider) or navigates from one object to another.

Links represent an end-to-end or customer service/service provider relationship, while aggregations represent a whole/part hierarchy that provides the ability to navigate from the whole (also known as an aggregate) to its parts.

The nature of the class

In the context of object-oriented analysis and design, we define a class as:

A class is a group of objects that have a common structure, common behavior, and common semantics.

An object is an instance of a class. A class is an abstraction of an object.

Abstract quality criteria

How do you tell if a class or object is well designed?

There are five commonly used measurement indicators, which are:

  • coupling

  • cohesion

  • sufficiency

  • integrity

  • basic

Coupling is a concept that comes from structured design. Coupling is a large measure of the strength of the relationship established between one module and another. Strong coupling makes systems complex, and if a module is highly related to other modules, it is difficult to understand, change, or modify independently. Complexity can be reduced by designing the system to minimize the coupling between modules.

The idea of cohesion also comes from structured design. Cohesion measures the degree to which elements within a single module (a single class or a single object) are related. The least desired cohesion is accidental cohesion, where completely unrelated abstractions are crammed into the same class or module. The most desirable cohesion is functional cohesion, where elements of a class or pattern work together to provide some clearly defined behavior.

A class or module should be sufficient, complete, and simple. By sufficient, I mean that a class or module should document enough characteristics of an abstraction to allow meaningful and efficient interactions. Otherwise, the component is rendered useless. Completeness means that the interface of a class or module records all the meaningful characteristics of an abstraction. Completeness is a subjective judgment, and providing all meaningful operations for an abstraction can be overwhelming to users and is often unnecessary, because many high-level operations can be done by low-level combinations, so classes and modules should be fundamental. Foundational operations are operations that can be effectively implemented only by accessing the underlying representation of the abstraction.

For example, if you design a collection class that removes elements but does not add them, the abstraction is inadequate and incomplete. Adding an element to a collection is a foundational operation and therefore needs to know the underlying representation, whereas adding four elements to a collection is not foundational and can be implemented on top of existing foundational operations.

OOAD: Unified Modeling Language for Object-oriented Analysis and Design

The act of drawing is not the point of analysis and design. A diagram is only a description of the behavior of the system, or the vision and details of an architecture. The only place where the system is conceived is in the designer’s mind, and as the design unfolds over time, it is recorded on a whiteboard or a napkin, just as it is on any high-tech device.

Having a well-defined, expressive representation is important to the software development process.

First, a standard notation allows an analyst or developer to describe a scenario, clarify an architecture, and then express it unambiguously.

Second, good representation removes unnecessary work from the brain, allowing it to focus on higher-level problems.

Finally, an expressive representation can take advantage of automated tools to eliminate many of the tedious consistency and correctness checks on these decisions.

Unified Modeling Language (UML) is the main modeling language for analyzing, specifying, and designing software systems.

UML diagrams can be divided into two broad categories: structural diagrams and behavior diagrams.

Structure diagrams are used to show the static structure of elements in a system. They describe the architectural organization of the system, the physical elements of the system, the run-time configuration of the system, and the domain-related elements of the business.

The structure diagram includes:

  • Package diagram

  • The class diagram

  • Component diagram

  • Deployment diagram

  • Object graph

  • Composite structure diagram

Structural diagrams are often used in conjunction with behavior diagrams to describe aspects such as systems, which are used to describe the dynamic behavioral semantics of a problem or its implementation.

The behavior diagram includes:

  • Use case diagram

  • Activity diagrams

  • The state machine diagram

  • Interaction diagrams

  • The sequence diagram

  • Communication diagrams

  • Interaction Overview diagram

  • Time to figure

As the system progresses and matures, your system patterns may represent different levels of detail.

The conceptual model documents the domain entities that exist in the system and their relationships to other domain entities in the system. Modeling at the conceptual level is done in business domain terms and should be technology-neutral.

The logical view of the system leverages concepts created in the conceptual model, establishes the meaning of key abstractions and mechanisms, and determines the architecture and overall design of the system.

The physical model of the system describes the specific software and hardware components of the system implementation. The physical model is technology-dependent.

Over time for a project, the design of the system evolves from conceptual maturity to logical maturity, and finally to physical maturity: conceptual model (business domain term) –> Logical model (system architecture design) –> physical model (software and hardware composition).