Domain Driven Design Flashcards
What is domain driven design?
Domain-driven design (DDD) is a software development approach that focuses on the complex and intricate relationships between a business and the data that it processes. In short, it focuses more on the businesses the technology should support.
Advantages:
Improved communication: DDD emphasizes the use of a ubiquitous language, which is a shared vocabulary that is used by all members of the development team and is based on the language used by domain experts. This can improve communication within the development team and between the team and domain experts.
Increased focus on the business domain: By focusing on the business domain, DDD helps ensure that the software being developed is aligned with the needs and goals of the business.
Enhanced flexibility: The domain model in DDD is designed to be flexible and adaptable, which can make it easier to make changes to the software as the needs of the business evolve.
Better understanding of the problem domain: By actively engaging with domain experts and working to understand the complexities of the business domain, the development team can gain a deeper understanding of the problem they are trying to solve, which can lead to better software design.
Improved design: The focus on the domain model in DDD can lead to the creation of a more cohesive and well-structured design, which can make the software easier to maintain and expand over time.
One disadvantage is that it can be time-consuming and resource-intensive, as it requires close collaboration between developers and domain experts and may involve multiple iterations of the design process. Additionally, DDD requires a deep understanding of the business domain, which may not always be feasible for developers.
What is strategic design?
Explorer the problem space and involves identifying the key business objectives and the desired outcomes for the software solution, and then defining the high-level requirements and architecture for the solution.
Understand and model how software handle different domain needs and how they relate to each other.
And involves the following elements:
- Core domain
- Sub-domains
- Bounded context
- Relationships
- Up-stream and Down-stream of data sharing
What is a sub-domain? And the 3 types of sub-domains.
- Core subdomain:
A core subdomain is a part of a larger domain that is particularly central or important to the business. A core subdomain is typically defined in terms of the business’s core business processes or activities. Examples are patient care in healthcare and designing products in manufacturing .
Creates competitive advantage and is implemented in-house.
- Supporting subdomain:
A supporting subdomain is a part of a larger domain that supports or enables the core subdomain, but is not itself central to the business’s core processes or activities. Examples are make sure laws and regulations are followed in finance or maintaining and repairing equipment in production.
Doesn’t create competitive advantage and is usually in-house/outsourced service.
- Generic subdomain:
A generic subdomain is a part of a larger domain that is common to many different types of businesses, and is not specific to a particular industry or sector. Examples are HR, marketing and financial management.
Doesn’t create competitive advantage and is usually adopted/bought service.
They are usually mapped to a single bounded context.
What is a Context map?
A context map describes the relationship between the various sub-domains.
What is the relationship context?
Is data downstream or up-stream?
What is a bounded context, and ubiquitous language?
Bounded context is a conceptual boundary within which a specific domain model applies. The idea of a bounded context is to define a clear separation between different parts of the domain model, so that the meaning of concepts and terms is clearly understood within that context.
For example, in a large organization, there may be multiple bounded contexts, each with its own domain model that applies only within that context. For example, there might be one bounded context for the sales team, with a domain model that includes concepts such as “customer,” “order,” and “invoice,” and another bounded context for the finance team, with a domain model that includes concepts such as “account,” “transaction,” and “balance.”
This is referred to as ubiquitous language. This makes sure everyone speaks the same “language” and the terms used in the code are the same as the business experts.
Jesper mener det er et IT system
What is tactical design?
Understand and model the detail of the domain
Consist of:
- Entities
- Value object
- Domain services
- Aggregates
- Repositories
- Factories (ikke gennemgået i undervisnignen)
What is a monolithic IT system and what are the problems of a this type of IT system?
A monolithic IT system is a single, large software application that is built as a single, unified entity. It is typically composed of a large number of components that are tightly integrated and that work together to provide a range of functions. They also often have one common relational database:
The problems with this is:
- It’s difficult to change database
- It’s almost impossible to remove or change aspects of the same
- Performance issues from synchronous transactions
What does a layered architecture consist of?
- User interface layer
The user interface (UI) layer is the presentation layer in a layered architecture. It is responsible for handling the interactions between the user and the application, and for displaying information to the user in a way that is easy to understand and use.
- Application layer
The application layer is the layer of a software application that contains the business logic of the application and is responsible for performing tasks and operations that are specific to the application. Meaning the code is not reusable outside of the context of the application.
In a web application, the application layer might include code that handles user requests, performs validation and authentication, and invokes the appropriate actions in the domain layer. The application layer is often implemented as a set of classes or modules that perform specific tasks or functions.
- Domain layer
The domain layer is the layer of a software application that contains the core domain model of the application and is responsible for representing the key concepts and relationships of the domain.
The domain layer is typically implemented as a set of classes or objects that represent the key entities, relationships, and behaviors of the domain. It is designed to be independent of the UI and application layers, so that it can be used and reused in different contexts.
A class that represents a customer in an e-commerce application. This class might include properties like customer name, address, and email, and it might include methods to retrieve orders placed by the customer, to update the customer’s account information, and to calculate the total amount spent by the customer.
- Infrastructure layer
This layer will be the layer that accesses external services such as database, messaging systems and email services. The IUserRepository interface designed in the domain layer and used in the application layer will be implemented in this layer and gain an identity. Similarly, the object that is used through the IIntegrationMessageBroker interface will have an implementation on this layer. Access to RabbitMq platform using AMQP protocol can be considered as an option.
Pieces of code that will be executed to communicate with the outside world such as network and file system are located in this layer.
What is an entity in tactical design?
An entity is a class that represents a unique and identifiable object in the domain. It has a unique identity that distinguishes it from other objects, and it is typically used to represent things like customers, products, and orders.
What is a value object in tactical design?
In Domain-Driven Design (DDD), a value object is a class that represents a value or concept that is not unique and does not have a separate identity. Value objects are typically used to represent things like money, dates, and addresses.
For example, a money value object might have properties like amount and currency, and it might have methods like add() and subtract(). The money value object would not have a separate identity of its own, but rather would be used to represent a specific monetary value.
These objects are immutable.
What is an aggregat in tactical design?
an aggregate is a group of related objects that are treated as a unit for the purpose of data changes. An aggregate has a root entity, which is the main object in the aggregate. The root entity is responsible for enforcing the invariants of the aggregate, and all changes to the objects within the aggregate should go through the root entity.
A customer entity might be related to several order entities (like order and items), and these entities might be combined into a customer aggregate.
What is a domain service in tactical design?
A domain service is a class that performs a specific operation in the domain. It does not have any state of its own and is not associated with any particular entity or value object. Domain services are typically used to implement business logic that does not naturally fit into any of the entities or value objects in the domain model.
For example, a tax calculation service might be a domain service that has a method like calculateTax(order: Order) that takes an order as input and returns the amount of tax that should be charged for the order. The tax calculation service would not have any state of its own and would not be associated with any particular entity or value object. It would simply provide a service that can be used by other parts of the application to perform tax calculations.
They operate on more than one object and is usually implemented as a function, but can also be implemented as a class.
What is a repository in tactical design?
A repository is a design pattern that provides a consistent interface for accessing and manipulating data stored in a database.
What is an event?
An event is an occurrence in the domain that represents something that has happened or that is about to happen. Events are used to communicate changes in the state of the domain model and to trigger actions or side effects.
Events are produced by entities, aggregates and domain services.
They are stored as log files.
What are the different context relationship types?
- Published language
The interacting BC (bounded context) agree on a common language by which they can interact with each other
- Open host service
BC specifies a protocol by which any other BC can use its services
- Shared kernel
Two BC’s use a common kernel of code as a common
- Customer/Supplier
One BC uses the services of another and is a stakeholder of that other BC. As such it can influence the services provided by that BC - Conformist
One BC uses the services of another but is not a stakeholder to that other BC - Anti-corruption layer
One BC uses the services of another and is not a stakeholder, but aims to minimize impact from changes in the BC it depends on by introducing a set of adapter.
