(Modern Software Architecture) The DDD Layered Architecture

Copyright

이 모든 내용은 Pluralsight에 Dino Esposito가 올린 'Modern Software Architecture: Domain Models, CQRS, and Event Sourcing'라는 강의의 세번째 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/modern-software-architecture-domain-models-cqrs-event-sourcing/table-of-contents). 강의 원작자분께 게시허가도 받았습니다.

Content

Discovering the Domain Architecture through DDD

The DDD Layered Architecture

The "Domain Model" Supporting Architecture

The CQRS Supporting Architecture

Event Sourcing

Designing Software Driven by the Domain

Outline

The Layers of a Software System

The Presentation Layer

The Application Layer

The Business Logic

Patterns for Organizing the Business Logic

The Domain Layer

The Infrastructure Layer

Segments of Code

Layer : a logical container for a portion of code

Tier : physical container for code

Modern application architecture

First. Build a model for the domain

Leveraging the strategic patterns of DDD, such as ubiquitous language and bounded context

Then. Layered Architecture with standard segments

Presentation(User experience), Application(Use-cases), Domain(Business logic), Infrastructure(Persistence)

The Presentation Layer

The presentation layer is responsible for providing some user interface to accomplish any tasks. Whatever command is issued from the presentation layer hits the application layer and from there is routed through the various remaining layers of the system.

Presentation can be seen as a collection of screens and each screen is populated by a set of data and any action that starts from the screen forwards another well-designed set of data back to the screen, the originating screen, or even some other screen.

Generally speaking we'll refer to any data that populates the presentation layer as the view model, and we'll refer to any data that goes out of the screen and triggers an action as the input model. Even though a logical difference exists between the two models, most of the time view model and input model just coincides.

The presentation layer is most critical part of modern applications

Responsible for providing the user interface to accomplish any required tasks

Responsible for providing an effective, smooth and pleasant user experience

Good attributes of a presentation layer are...

Task-based nature

Device-sensitive and friendly

User-friendly

Faithful to real-world processes

The Application Layer

The application layer is an excellent way to separate interfacing layers, such as the presentation layer and the domain layer. In doing so, the application layer gives an incredible contribution of clarity to the entire design of the application.

The application layer is just where you orchestrate the implementation of the applications use cases

The Application Layer

Reports to the presentation

Serves ready-to-use data in the required format

Orchestrates tasks triggered by presentation elements by presentation element

Use-cases of the application's frontend

Doubly-linked with presentation

Possibly extended or duplicated when a new frontend is added

The link between the presentation and application layer should be established right when you design the user interface, because each form you display has an underlying data model that becomes the input of the methods invoked in the application layer. In addition, the result of each application layer method is just the content  that you use the fill up the next screen displayed to the user. Application layer is absolutely necessary, but it strictly depends on what you actually display to users and what you display to users has to guarantee a fantastic user experience. This is why a top-down approach to software development is today absolutely crucial.

The Business Logic

In the design of a software system, initially you go through three key phases

1. Getting to know as much as possible about the business domain, splitting the domain into simpler subdomains

2. Learn the language of the business domain

3. Split the business domain in bounded contexts

Then... What's Next?

4. It's all about implementing all business rules and organizing the business logic in software components

Business Logic (An Abstract Definition)

The business logic of a software system is made of two main parts

1. Application logic

Dependent on use-cases : Application entities, Application workflow components

In DDD

Data transfer objects : containers of data being moved around to and from presentation screens

Application services : the components that coordinate tasks and workflows

2. Domain logic

Invariant to use-cases : Business entities, Business workflow components

In DDD

Domain model : for the entities that hold data in some behavior and domain services for any remaining behavior

Domain services : for any remaining behavior and data that for some reason don't fit in the entities

In general terms, both application and domain logic are made of entities to hold data and the workflows to orchestrate behavior

What is Domain logic?

Domain logic is all about how you bake business rules into the actual code

A business rule is any statement that explains in detail the implementation of a process or describes a business related policy to be taken into account.

Three Common Patterns for organizing the business logic

1. Transaction script

The transaction script pattern is probably the simplest possible for business logic, and it is entirely procedural.

a. System actions - Each procedure handles a single task

The word script indicates that you logically want to associate a sequence of system carried actions, namely a script, with each user action.

b. Logical transaction - end-to-end from presentation to data

The word transaction in this context has very little to do with database transactions, and it generically indicates a business transaction you carry out from start to finish within the boundaries of the same software procedure.

c. Common subtasks - split into bounded sub-procedures for reuse

As is, transaction script as a pattern has some potential for code duplication. However, this aspect can be easily mitigated identifying common subtasks and implementing them through reusable routines.

In terms of architectural design, the transaction script pattern leads to a design in which actionable UI elements in the presentation layer invoke application layers end points and these end points run a transaction script for just each task.

2. Table module

As the name suggests, the table module pattern heralds a more database-centric way of organizing the business logic. The core idea here is that the logic of the system is closely related to persistence and databases. 

a. One module per table in the database

So, the table module pattern suggests you have one business component for each primary database table.

b. Module contains all methods that will process the data - Both queries and commands

The component exposes end points through which the application layer can execute commands and queries against a table, say orders, and the link or just related tables say order details.

c. May limit modules to "significant" tables - Tables with only outbound foreign-key relationships

In terms of architectural design, the table module pattern leads to a design in which presentation calls into the application layer and then the application layer for each step of the workflow identifies the table involved, finds the appropriate module component, and works with that.

3. Domain model

The term domain model is often used in DDD. However, in DDD, domain model is quite a generic term that refers to having a software model for the domain. More or less in the same years in which Eric Evans was using the term domain model in the context of the new DDD approach, Martin Fowler was using the same term, domain model, to indicate a specific pattern for the business logic. Fact is, the pattern, the main model is often using DDD, though it's not strictly part of the DDD theory. 

a. Aggregated objects - Data and behavior

The domain model pattern suggests that architects focus on the expected behavior of the system and on the data flows that make it work. When implementing the pattern, at the end of the day you build an object model, but the domain model pattern doesn't simply tell you to code a bunch of C# or Java classes. The whole point of the domain model pattern is hitting an object-oriented model that fully represents the behavior and the processes of the business domain. When implementing the pattern, you have classes that represent live entities in the domain. These classes expose properties and methods, and methods refer to the actual behavior and the business rules for the entity. Aggregate model is a term used in domain-driven design to refer to the core object of a domain model, and we'll see more about aggregates in the next module.

b. Persistence agnostic

c. Paired with domain services

The classes in the domain model should be agnostic to persistence and paired with service classes that contain just the logic to materialize instances of classes to and from the persistence layer. A graphical schema of a domain model has two elements, a model of aggregated objects and services to carry out specific workflows that span across multiple aggregates or deal directly with persistence.

Where do you start designing the business logic of the real-world system? The basic decision is just one.

Would you go with an object-oriented design? functional design? Or just a procedural approach?

The Domain Layer

In the domain-driven design of a software application, the business logic falls in the segment of the architecture called domain layer.

Domain Layer - Logic invariant to use-cases

Domain model

business domain

not necessarily an implementation of the aforementioned domain model pattern

Domain services

related and complementary set of domain-specific services

the primary responsibility of domain services is persistence

Models for the business domain

In the implementation of a domain layer, as far as the model is concerned, we have essentially two possible flavors.

Domain Model

1. Object-oriented entity model (entity model for short)

An entity model has two main characteristics.

a. DDD conventions (factories, value types, private setters)

Classes follow strict DDD conventions, which means that for the most part these classes are expected not to have constructors, but factories, use value types over primitive types, and avoid private setters on properties.

b. Data and behavior

These classes are expected to expose both data and behavior.

Anemic model

Often considered an anti-pattern, the anemic domain model is yet another possibility for coding business logic.

Plain data containers

Behavior and rules moved to domain services

An object-oriented domain model is commonly defined anemic if it's only made of data container classes with only data and no behavior. In other words, an anemic class just contains data and the implementation of workflows and business rules is moved to external components, such as domain services.

2. Functional model

tasks are expressed as functions.

Domain Services

Domain services complement the domain model and contain those pieces of domain logic that just don't fit into any of the other created entities. This covers essentially two scenarios. One is classes that group logically related behaviors that span over multiple entities. The other is the implementation of processes that require access to the persistence layer for reading and writing and access to external services, including legacy code.

The Infrastructure Layer

Set of the fundamental facilities needed for the operation of a software system

Fundamental Facilities of Software Systems

Database (more in general, Persistence is crucial then others below)

Security, Logging & Tracing, Inversion of Control, Caching, Networks...

When it comes to the infrastructure layer, I like to call it as the place down where the technologies belong. So, necessary to fuel the entire system, but not binding the system to any specific products, the infrastructure layer is where you start dealing with configuration details, things like connection strings, file paths, TCP addresses, or URLs. To keep the application decoupled from specific products, you sometimes want to introduce facades to hide technology details while keeping the system resilient enough to be able to replace technologies at any time in the future with limited effort and costs.

출처

이 모든 내용은 Pluralsight에 Dino Esposito가 올린 'Modern Software Architecture: Domain Models, CQRS, and Event Sourcing'라는 강의의 세번째 챕터를 듣고 정리한 것입니다(https://app.pluralsight.com/library/courses/modern-software-architecture-domain-models-cqrs-event-sourcing/table-of-contents). 제가 정리한 것보다 더 많은 내용과 Demo를 포함하고 있으며 최종 Summary는 생략하겠습니다. Microsoft 지원을 통해 한달간 무료로 Pluralsight의 강의를 들으실 수도 있습니다.