Applying Domain-Driven Design in Practice

2026-05-26T00:00:00+00:00

Photo by Josh Ausborne, 2007.

This is part 4 of a series of blog posts on Domain-Driven Design:

High level system analysis and design with Domain-Driven Design

Implementing business logic with Domain-Driven Design

Designing software architecture with Domain-Driven Design

Applying Domain-Driven Design in Practice

Domain-Driven Design is an approach to software development that focuses on, as Eric Evans puts it, “tackling the complexity in the heart of software”. And what is in the heart of software? The business domain in which it operates. Or more specifically: a model of it, made of code. That is, the code that implements the business logic that comes into play when solving problems within the realm of a particular business activity.

DDD is not just about writing code though. It’s a whole methodology that touches on business needs, requirements gathering, organizational dynamics, high level architectural design, and lower level patterns for implementing software intensive systems.

As a result, DDD offers a treasure trove of concepts, patterns and tools that can be applied to any software project, regardless of the size and complexity.

In this series of blog posts we’re going to explore many aspects of DDD. We will be following the structure laid out by Vlad Khononov’s excellent book on the topic “Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy”. So you can think of this series as a summary of that book. An abridged version that can serve as a review for anybody who has read it; but also as an entry point for people who are new to DDD.

Applying Domain-Driven Design in Practice

Section 10: Design heuristics

At this point in the series we’ve explored a number of tools and patterns to work with DDD. We also touched on what kinds of problems they solve and how to apply them. We learned how to analyze business domains, how to design high level components, how to implement business logic, how to organize code bases and how system components interact. In this section, we’ll discuss a series of heuristics that we can use to make decisions as to when to apply these techniques.

Bounded contexts

When designing bounded contexts, that is, the physically separated system components, size is not a useful metric. Instead, consider the model that they contain, and make sure they are cohesive. In fact, breaking down a system into many bounded contexts too early is a form of premature optimization that can be costly when done wrongly. And at the beginning of a project, when domain knowledge is likely as low as it will ever be, it’s easy to get it wrong.

A system that’s broken up into many physical components is more expensive to maintain because changes usually propagate across them. This is due to obvious technical reasons, but can also be exacerbated by organizational reasons. For example, when the bounded contexts are maintained by different teams.

So, start with bounded contexts with broader boundaries. And then, as the system matures and the team acquires more domain knowledge, refactor into separate system components when needed.

Business logic implementation patterns

At its core, DDD is about letting the business domain drive software design decisions. This means that we should strive to use the right tool for the job. As we’ve discussed before, the level of complexity of the domain at hand is what determines which business logic implementation patterns should be applied. The more complex the problem at hand, the more elaborate the chosen pattern for the solution. Luckily, we learned that we can classify subdomains by their level of complexity, so we can use subdomain types to drive our decision making. This is explained in this diagram:

Complexity, subdomain types and particular business requirements are what drive how we implement business logic.

Architectural patterns

Once we have decided how to implement the business logic, it’s easy to decide which architectural pattern to develop our system with. The decision on what architecture to use is dependent on the business requirements and the business logic pattern we’ve selected:

The architecture is driven by whether we need multiple models to represent the same data and the business logic pattern.

If a system is using an event sourced domain model, or it needs multiple persistence models, CQRS is almost a requirement. Otherwise the system would be very limited in its querying capabilities. For a plain domain model, a ports and adapters architecture is ideal because it allows the domain model to be completely decoupled from data persistence concerns. For the active record pattern, it’s best to go with a layered architecture that includes a service layer. The service layer orchestrates the active records to execute the business operations. Finally, a simple three-layered architecture is sufficient for transaction scripts, where no advanced abstractions are needed to accommodate complex business logic.

Testing strategy

Generally, there are three kinds of automated tests: end-to-end, integration and unit tests. A test suite in any given system can choose to lean more into one kind and less on the others, forming one of three possible scenarios: the testing pyramid, diamond and reverse pyramid.

A test suite can be imbalanced in terms of the kinds of tests that it implements. Depending on the kind of system that is being tested, it is often more valuable to have more tests of one kind and fewer of others.

How does it choose? It does so based on the patterns that it uses for implementing its business logic and its architecture. Here’s the decision tree:

The patterns we chose for business logic and architecture often give us a good idea of what kinds of tests we should focus more on.

A domain model leans heavily on components that are testable as units. Plain old objects like aggregates and value objects can be very well covered in isolation by unit tests. Active records on the other hand, are tightly coupled with database interaction logic. In these cases, business logic is usually distributed between the active records themselves, the database, and service objects. Integration tests are the most appropriate kinds of tests for this type of system, as they exercise multiple layers at once, and how they interact. Finally, pure transaction script systems benefit more from end-to-end tests. This is because their abstractions are shallow, so the system components are often hard to decompose and test in a meaningful way. Also, their logic is simple, so tests that exercise entire workflows can be very effective.

Section 11: Evolving design decisions

Of course, software very rarely stays static. On the contrary, it evolves. So far we’ve been mainly discussing how to create software that’s well designed using DDD’s concepts. However, if change is not managed correctly, not even the best designed software can resist becoming an unmaintainable mess that is prohibitively expensive to evolve. In this section we will discuss the main forces that produce change, and how to cope with it.

Changes in the domain

As we’ve seen before, it is crucial to know the business domain in which the software that we build operates. In particular it’s important to decompose the domain into many subdomains and identify their type: core, supporting and generic. That knowledge drives important design decisions. As an organization evolves and grows though, there’s a good chance that the subdomains that compose it change from one type to another. Our designs need to react accordingly to these changes.

Core and supporting subdomains can become commoditized and become generic. For example, when off-the-shelf solutions become available that cover their functionality. Through emerging business opportunities, generic and supporting subdomains can become core subdomains. This is the case when the company discovers a competitive advantage in an aspect of its business that it thought was nothing special. Likewise, a core subdomain can become a supporting one when it stops representing a business advantage but still remains very unique to the business, prompting a divestment and simplification of its logic. Finally, generic subdomains being served by off-the-shelf solutions may be costly to acquire or integrate. In such cases, a company might decide to go with an in-house solution, turning it into a supporting subdomain.

Subdomain types are not static. These often change during the lifetime of a business.

Changes to subdomains directly affect the bounded contexts (i.e. the system’s high level physical components, applications, services, etc) that work with them, and their related high level design decisions. Namely, their integration patterns and their ownership.

If a subdomain is becoming a core subdomain, we need to consider how its bounded contexts are integrated with others. A core subdomain calls for an anticorruption layer in order to protect its model and for an open-host service with a published language in order to protect the models of its consumers. So, these patterns need to be implemented for the bounded contexts in the newly born core subdomain. Also, separate ways is a big no-no for core subdomains. We don’t want important and complex business logic to be duplicated and risk inconsistencies. So we have to make sure to move away from that, and implement one of the consumer-supplier patterns discussed earlier.

The ownership strategy is also determined by the type of subdomain. When a subdomain morphs into a core subdomain, development needs to be moved in-house, or to trusted development partners. This is where domain experts are closest and the highest skill level is available. Supporting subdomain implementation and generic subdomain integration on the other hand, are fine to be outsourced or handled by more junior teams.

Of course, a change in subdomain should also affect the way in which the business logic is modeled. If the change is in the direction of more complexity, for example when a supporting subdomain becomes a core subdomain, that will manifest in the code base as an increase in difficulty when implementing new features, duplication and bugs; as the original design can no longer support the complexity that the business demands.

In these cases, we need to refactor the business logic and use the pattern that best supports the new subdomain complexity needs. Here are a few pointers on how to transition from simpler business logic implementation patterns to more complex ones:

Transaction script to active record. These are very similar in that they both model the business as procedural scripts. The advantage of active record is that it provides an abstraction over complex data structures. So, when refactoring transaction scripts into active records, look for direct data access and manipulation with SQL and move that logic into the active record objects. Start with the most complex structures.
Active record to domain model. When the logic that orchestrates the active records becomes overly complex, duplicated and/or inconsistent, refactor into a domain model. Identify data structures that could be made immutable and encapsulate them and their related logic as value objects. Look for all logic that modifies system state and encapsulate it as methods inside the active records, then make all setters private. This makes sure all modifications of state happen inside the objects that are getting modified. These are your first rudimentary entities and commands. Next, examine the object hierarchies that are emerging, as these are your aggregates. Use the guiding rules of keeping them small, their transactional boundaries tight, and ensuring they contain only the data they need to be strongly consistent. Finally, identify a root for each aggregate. This will be the entry point for their public interface.
Domain model to event sourced domain model. In order to transition into an event sourced domain model, the key is to stop modifying the aggregates’ data directly and instead, produce domain events that reflect the changes. Make sure to capture those events reliably, and implement the projections necessary to take collections of events and turn them into fully hydrated aggregates. One tricky part of the migration is how to deal with the existing state-based data. There are two ways of doing this: One way is to model a “migration” event, which represents each aggregate in full, as they were before event sourcing was implemented. Another way is to try and reverse engineer a series of past events out of each aggregate in an attempt to approximate their history as if event sourcing was always present.

Organizational changes

Organizational changes should also trigger changes in the system’s design. Namely, the strategies that bounded contexts use to communicate with each other. These can change as a result of changes in the communication and collaboration levels of the teams involved.

For example, when the development division grows to the point that new teams are created, a single bounded context that was maintained by the original smaller team needs to be separated into finer granularity ones. This way we maintain single team ownership for bounded contexts.

Additionally, when teams that own bounded contexts that are tightly integrated grow distant, the integration patterns used need to evolve to reflect the new reality of the organization. A partnership style integration should evolve into a customer-supplier or even separate ways one.

Domain knowledge changes

At its core, DDD is about having business domain knowledge drive software design decisions. As a greater understanding of the problem domain develops, so too should the design evolve to incorporate the new knowledge.

The beginning of a project is often the time when we have the weakest understanding of the domain. We can use this realization to drive the decisions related to how we will decompose a system into bounded contexts. At the early stages, it’s better to err on the side of fewer separations, and bigger bounded contexts with wider boundaries. This is because a premature separation that ends up being wrong is very costly to live with and very costly to fix later. The contrary is much less expensive and less risky: decomposing a monolithic system later when domain knowledge has solidified and we’re better equipped to make those decisions.

Unfortunately, it is also possible for domain knowledge to get lost over time. Documentation can become stale and business experts and developers may leave the organization and leave a vacuum of knowledge. It is important to be proactive in maintaining the domain knowledge via training, maintenance of documents, and ongoing discussions. The EventStorming workshop is a good tool for recovering lost knowledge.

Growth

In software projects, growth is always desirable. After all, growth means that the software is useful, that the project is successful, and that stakeholders and users want to continue investing in it and evolving it with new capabilities. Unregulated growth however, can turn a code base into a big ball of mud. This happens when changes and additions are done haphazardly without evaluating the original design decisions.

To make sure a code base grows in a healthy manner, the key principle is this: identifying and eliminating accidental complexity. That is, all complexity that is not essential to the problem domain. Complexity that arises by accident, due to bad design decisions. Here are a few aspects to keep in check to prevent build up of accidental complexity:

Subdomains: As the business grows, the subdomains also morph, their types change and their boundaries shift. It’s important to keep track of how the subdomains are evolving because that gives us the ability to choose the appropriate technical solutions for them.
Bounded contexts: Growth can also cause the boundaries of bounded contexts to become hazy. Models from other contexts can leak and bounded contexts can become bloated with logic that belongs elsewhere or overly dependent on others. We need to be vigilant of this and make sure to keep bounded contexts focused and their boundaries solid. Make sure they stay internally cohesive, and split logic into new bounded contexts when needed.
Aggregates: Similar to bounded contexts, unregulated growth can cause aggregates to accumulate extraneous logic, expanding them unnecessarily. As we know, the golden rule for aggregates is for them to be only as big as they need to be to include only the data that needs to be strongly consistent for them to be able to fulfill the business requirements. We need to make sure aggregates only contain the logic that’s closely related to their purpose in the domain. When necessary, new aggregates can be created for new logic.

Section 12: Domain-driven design in the real world

Some common misconceptions about DDD are that it can only be applied in greenfield projects where the entire team are DDD experts and that all the tools need to be included wholesale for the practice to be effective. This couldn’t be further from the truth. In fact, brownfield projects that have already proven their business value but have accumulated tech debt are the ones that stand to benefit the most from applying DDD. In these situations, the patterns we’ve discussed can be gradually introduced, within the context of a greater effort to modernize the code base.

Strategic analysis

Unsurprisingly, when introducing DDD into an organization, the first step should be to understand its business domain. To this end, key questions ought to be asked:

What is the organization’s business domain?
Who are its customers?
What service or product does it provide to its customers?
Who are its competitors?

That’ll give us a general understanding of its business goals. Then, a good place to look next is the organizational structure. The divisions, departments, etc. That’ll give us insight into the subdomains. Next, we should analyze these subdomains and identify their types.

The core subdomains will be the areas of business differentiation and competitive advantage. Some intellectual property, patent or algorithm that gives them an edge against their competitors. Unfortunately, you are also likely to find core subdomains in the software that’s worst designed. Usually legacy systems that everybody is afraid of refactoring due to their immense business value. For generic subdomains, identify where off the shelf solutions are deployed or open source components are integrated. Finally, supporting subdomains will be whatever is left. Those applications that have been developed in house but are not particularly interesting. Mostly CRUDs and ETLs. They may also be badly designed, but the pain they cause is much less severe because they don’t change too often nor do they offer great business value.

Next, dig deeper and explore the current design. Identify the high level physical software components: applications, services, backend jobs. These likely won’t be clearly defined bounded contexts in the DDD sense, but will give you a starting point in moving in that direction for system decomposition. The key here is to identify the components that have decoupled lifecycles. The ones that can be evolved, built and deployed independently. Next, identify the patterns that have been used to implement their interactions with one another, their internal architecture and business logic. Make sure they are appropriate for the level of complexity of the business problems they are addressing.

Finally, identify where domain knowledge has been lost and endeavor to recover it. As mentioned earlier, the EventStorming workshop is a great exercise to go through for this.

Modernization strategy

When it comes to modernizing a code base by moving it in the direction of DDD, it’s better to start small and do it gradually. “Big rewrite” projects are rarely successful, and should be avoided. Here are some suggestions to keep in mind:

When working on a big monolithic system, it’s often useful to start by making its logical boundaries explicit along the lines of the subdomains that it contains. Separation into bounded contexts would be the ideal, but it is often too big a task to undertake in one fell swoop. For example, instead of having namespaces and modules reference technical patterns, it is often useful to have them reflect the subdomains. That is, instead of namespaces like Store.WebUI, Store.Infrastructure or Store.Services; that can be reorganized into the likes of Store.Inventory, Store.OrderProcessing, Store.ShoppingCart. That can become the basis for further physical separation down the line. Also remember to apply similar separation to other places where code lives, like stored procedures in the database or serverless functions in a cloud provider.

When it comes to physical separation of modules, starting small is also advisable. Instead of decomposing a big monolith into many microservices right away, identify one or two modules that would provide the highest business value and extract those. The logical boundaries discussed in the previous paragraph are a good guide, as these can be promoted into physical boundaries.

For business logic and internal component architecture, look for the pain. The areas of a code base where matters of core subdomains are handled, and which have been implemented using inappropriate patterns for their level of complexity, are usually the ones to attack first, as they will provide the most benefit for being in better shape. These are the areas that produce more pain for developers, where changes are overly expensive. Beware of big jumps though. Refactoring transaction scripts directly into an event sourced domain model is a risky proposition. Tackling the entire codebase all at once is also dangerous. It’s better to do it gradually, picking specific use cases or business operations and evolving them one by one, step by step. Continue to avoid a big rewrite, and instead operate in small incremental steps.

This migration can be done in place, but also, the strangler fig pattern can be a good choice for these. With this pattern, the main idea is to create a new component to replace an old legacy one. The new strangler component grows gradually as more and more features are migrated from the old one, until it becomes obsolete and gets fully replaced. In the period of time in which both old and new components are “alive”, a facade is put in between them and the rest of the system. This facade takes care of gradually re-routing messages to the new component as they come online. Ultimately, the facade gets removed when the new component is ready to handle all the requests that the legacy one used to support.

With the strangler fig pattern, we develop a new component that gradually replaces a legacy one. During the transition, both components work with the same database, and the rest of the system interacts with them through a facade.

Selling Domain-driven design

Finally, don’t fall into the trap of thinking that you need to sell your entire organization on DDD in order to start using it. DDD is first and foremost an engineering practice, and as engineers it is up to us to use it. It doesn’t need to be an organizational strategy, you can still reap the benefits of DDD by incorporating it into your professional toolbox.

For example, you can make the decision to develop and use the ubiquitous language. Listen to domain experts and other stakeholders to learn the terms and concepts and make sure the code speaks the same language. Also, use that language yourself in all project communications. Try to identify and resolve inconsistencies. Do this with the help of domain experts, who are often happy to talk to developers, even in informal settings.

For big systems, explore the options for decomposition using bounded contexts as guiding principles, even if not calling them out by name explicitly. Think of the principles behind the pattern: “All-in-one” solutions are often ineffective and incur high cognitive load and complexity. So, alleviate this by separating them into decoupled physical components, each with its own model of the domain, geared towards solving specific problems. Remember that high ownership is a desirable trait. To that end, ensure that a given code base is owned by a single team. This way we can avoid friction when the teams cannot collaborate effectively.

Similarly, when implementing business logic using the domain model patterns we’ve seen, think about the principles behind them. About their purpose and advantages when compared to the alternatives. To protect data consistency, you can make transactional boundaries explicit by leveraging aggregates. Aggregates are great places to encapsulate related business logic. This prevents logic from being duplicated, becoming out of sync, and far away from the data structures that it manages. For the same reasons, prefer application logic implemented in aggregates instead of stored procedures. Make sure the aggregates and the transactional boundaries they represent stay small. This keeps aggregate complexity from getting out of hand and also helps with performance. Also, when long term data consistency is a concern, traditional log files fall short. In these cases event sourcing is more reliable.

At the end of the day, remember to be pragmatic with DDD. It is not an all-or-nothing proposition. Feel free to pick the tools, patterns and practices that will give you the greatest bang for the buck in your particular situation. Even if they are different from the ones we’ve discussed so far. The most important thing is to come up with effective models, cultivate a ubiquitous language, and work closely with domain experts. Keep in mind that DDD is not necessarily about value objects, entities and aggregates. DDD is about putting the business domain front and center, analyzing it and letting it drive the design, and coming up with effective models of the domain that can solve specific problems.

Finally

And with that we’ve reached the end of this series of blog posts discussing domain-driven design. Like I mentioned at the beginning, this series is greatly inspired by Vlad Khononov’s book: “Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy”. This book does a great job in democratizing DDD, as Evans’ original work can be somewhat dense at times. And while I went through a lot of the topics that he covers in his book, there are many more that I didn’t, like EventStorming, microservices, event driven architectures, data warehouses, lakes and meshes, and their relationship with DDD. So I can’t recommend strongly enough that you pick it up yourself. It is a great addition to the shelf of any software engineering professional. My hope is that this series has served as a solid introduction and encourages readers to dig deeper into the topic.

Designing software architecture with Domain-Driven Design

2026-05-05T00:00:00+00:00

Photo by Juan Pablo Ventoso, 2023.

This is part 3 of a series of blog posts on Domain-Driven Design:

High level system analysis and design with Domain-Driven Design

Implementing business logic with Domain-Driven Design

Designing software architecture with Domain-Driven Design

Applying Domain-Driven Design in Practice

As a result, DDD offers a treasure trove of concepts, patterns and tools that can be applied to any software project, regardless of the size and complexity.

Designing software architecture with Domain-Driven Design

Section 8: Architectural patterns

Now that we’ve seen various patterns for implementing business logic, i.e. “the heart of software”. We turn our attention to architecture.

Indeed, the business logic is the raison d’être for a software application. But applications have other responsibilities that are also important. Like interacting with users, receiving requests and returning results, storing data, interfacing with external services. In order to balance all these concerns and make sure the code base does not devolve into an unmaintainable big ball of mud, we need to be intentional in how we organize it. We need to design its architecture.

That is, the rules and principles that we follow to organize the various aspects of the code base and create clear boundaries between them. In essence, software architecture is about defining a system’s big logical components, their dependencies and interactions.

In this section we will see three common architectural patterns: layered architecture, ports and adapters, and command query responsibility segregation.

Layered architecture

The layered architecture is one of the most common architectural patterns out there. It has been present, in one form or another, for a long time. The main idea of the pattern is to separate applications into three layers: the presentation layer, the business logic layer, and the data access layer.

Layered architecture.

The presentation layer (or user interface layer) is meant to implement the mechanisms through which consumers interact with the application. This means the app’s graphical user interface (GUI), command line interface (CLI) or application programming interface (API).

The business logic layer (or domain layer) implements the business rules, validation and invariants. This is where we’d implement the patterns that we’ve seen so far like transaction script, active record, or a domain model.

Sometimes, an additional “service layer” or “application layer” emerges between the presentation and business logic layers. When the domain logic needs some level of orchestration, such as it is the case with active records and domain models, it is often useful to further separate the presentation and business logic layers by exposing a sort of “public interface” to the domain. That is, a series of procedures (i.e. transaction scripts) that serve as a facade that maps presentation layer actions (e.g. user interactions) to business domain transactions.

The service layer sits between the presentation and business logic layers. It implements a series of actions which map closely to the operations exposed to users by the presentation layer.

Here’s an example of refactoring a “fat” controller by introducing a service layer:

// This is an MVC controller that implements a REST API endpoint for adding
// items to a shopping cart. It lives in the application's presentation layer
// and leverages business logic layer components to run its logic.

namespace MvcEcommerce.WebApi.Controllers;

[Route("api/[controller]")]
[ApiController]
public class QuoteItemsController : ControllerBase
{
    // ...

    // This action takes care of processing user input, fetching HTTP context
    // values like cookies, responding with proper HTTP status codes and
    // orchestrating the business logic.
    [HttpPost]
    public async Task<ActionResult> Post([FromBody] QuoteItemPost payload)
    {
        var quoteId = _quoteCookieManager.GetQuoteIdFromCookie(Request);
        var quote = await _quoteRepository.FindOpenByIdAsync(quoteId);
        if (quote == null) return NotFound("Quote not found");

        var product = await _productRepository.FindByIdAsync(payload.ProductId);
        if (product == null) return NotFound("Product not found");

        var matchingQuoteItem = quote.GetItemBy(productId: payload.ProductId);
        if (matchingQuoteItem != null) return BadRequest("Item already exists");

        var quoteItem = new QuoteItem()
        {
            Product = product,
            Quantity = payload.Quantity,
        };
        quote.Items.Add(quoteItem);

        await _quoteRepository.UpdateAsync(quote);

        return Ok(quoteItem);
    }
}

This controller does too much. We can move a lot of its logic into a service layer component:

namespace MvcEcommerce.WebApi.Controllers;

[Route("api/[controller]")]
[ApiController]
public class QuoteItemsController : ControllerBase
{
    // ...

    // After refactoring, this action is now much simpler and only concerned
    // with presentation layer issues. That is, handling user input and the HTTP
    // specific aspects of request processing. It relies on the service layer to
    // orchestrate the business logic.
    [HttpPost]
    public async Task<ActionResult> Post([FromBody] QuoteItemPost quoteItem)
    {
        try
        {
            var quoteId = _quoteCookieManager.GetQuoteIdFromCookie(Request);

            var result = await _quoteItemCreator.Run(new() {
                QuoteId = quoteId.Value,
                ProductId = quoteItem.ProductId,
                Quantity = quoteItem.Quantity
            });

            return Ok(result);
        }
        catch (EntityNotFoundException ex)
        {
            return NotFound(new ErrorMessage(ex));
        }
        catch (DomainException ex)
        {
            return BadRequest(new ErrorMessage(ex));
        }
    }
}

// This service object implements all the domain logic orchestration that
// used to live in the controller. Notice how this code is not concerned with
// presentation layer responsibilities like handling HTTP specific logic, for
// example.

namespace MvcEcommerce.ServiceLayer.Services;

public class QuoteItemCreator
{
    // ...

    public async Task<QuoteItem> Run(InputPayload payload)
    {
        var product =
            await _productRepository.FindByIdAsync(payload.ProductId) ??
                throw new EntityNotFoundException("Product not found");

        var quote =
            await _quoteRepository.FindOpenByIdAsync(payload.QuoteId) ??
                throw new EntityNotFoundException("Quote not found");

        var matchingQuoteItem = quote.GetItemBy(productId: payload.ProductId);
        if (matchingQuoteItem != null)
            throw new DomainException("Item already exists");

        var quoteItem = new QuoteItem()
        {
            Product = product,
            Quantity = payload.Quantity,
        };
        quote.Items.Add(quoteItem);

        await _quoteRepository.UpdateAsync(quote);

        return quoteItem;
    }
}

Finally, the data access layer is meant to provide the means of interacting with persistent storage like databases, search indexes, file systems, etc. In modern systems, this layer has evolved into more of a “infrastructure” layer, and taken on the responsibility of interacting with external APIs and other kinds of web services. So, not strictly limited to pure “data storage”.

The communication between these layers is one-way, from top to bottom. Meaning that the presentation layer holds a reference to, depends on, and calls to the business logic layer. Same with the business logic layer to the data access layer.

This communication pattern is excellent for active record and transaction script based systems. For domain models, it begins to fall a bit short. This is because the business logic depending on the data access logic contradicts one of the core principles of domain models: the fact that they are supposed to be plain old objects, with no dependencies on frameworks or infrastructure.

Ports and adapters

The ports and adapters architecture leverages the dependency inversion principle to address the shortcomings of the traditional layered architecture and make it ideal for implementing domain models. Its main advantage is that it decouples the business logic layer from the infrastructure.

The dependency inversion principle dictates that, instead of higher level components directly depending on and referencing lower level ones; it is the lower level components that should depend on the higher level ones. This is done by the higher level components defining contracts for the lower level components to implement, and through those, be integrated into the higher level components’ workflows. The higher level components only ever interact with the lower level ones through the contracts that they themselves define.

Case in point: instead of the business logic depending on data access logic, like in the layered architecture; the business logic layer takes center stage and defines the contracts that the data access layer (and really, all infrastructure) must abide to in order to be usable to the business logic.

And that’s precisely where the ports and adapters name comes from. The business logic defines contracts/interfaces, AKA “ports”; and the infrastructure provides concrete implementations for these interfaces which can talk to external components: the “adapters”. Then, application bootstrapping logic, or dependency injection, takes care of supplying the concrete objects (or adapters) to the abstract interfaces (or ports) that the business logic specifies. This is exactly what a domain model calls for.

Here’s an example of a minimal, thin vertical slice of an application designed using the ports and adapters pattern:

The business logic implements some procedure which necessitates interacting with the database, an email delivery service, and a payment processor:

namespace Ecommerce.BusinessLogicLayer.Services;

public class OrderCreator
{
    // This service does not directly depend on concrete classes. Instead, it
    // references abstract interfaces. The concrete implementations are given
    // via dependency injection through the constructor.
    private readonly IOrderRepository _orderRepository;
    private readonly IOrderConfirmationMailer _orderConfirmationMailer;
    private readonly IPaymentGateway _paymentGateway;

    public OrderCreator(
        IOrderRepository orderRepository,
        IOrderConfirmationMailer orderConfirmationMailer,
        IPaymentGateway paymentGateway
    ) {
        _orderRepository = orderRepository;
        _orderConfirmationMailer = orderConfirmationMailer;
        _paymentGateway = paymentGateway;
    }

    public async Task<Order> Run(InputPayload payload)
    {
        // ...

        var order = new Order(payload);

        var result = _paymentGateway.SubmitPayment(order);
        if (!result.IsSuccess)
            throw new DomainException("Error processing payment");

        await _orderRepository.Save(order);

        await _orderConfirmationMailer.Send(order);

        return order;
    }
}

The business logic layer also defines its ports. That is, interfaces that the infrastructure layer will have to implement:

namespace Ecommerce.BusinessLogicLayer.Interfaces;

public interface IPaymentGateway
{
    PaymentTransactionResult SubmitPayment(Order order);
}

public interface IOrderRepository
{
    Task<Order> Save(Order Order);
}

public interface IOrderConfirmationMailer
{
    Task Send(Order order);
}

The infrastructure layer provides implementations for these interfaces:

namespace Ecommerce.InfrastructureLayer.Payments;

public class AuthorizeNetPaymentGateway : IPaymentGateway
{
    public AuthorizeNetPaymentGateway(/* ... */) { /* ... */ }

    public PaymentTransactionResult SubmitPayment(Order order) { /* ... */ }
}

namespace Ecommerce.InfrastructureLayer.Repositories;

public class OrderRepository : IOrderRepository
{
    public OrderRepository(/* ... */) { /* ... */ }

    public Task<Order> Save(Order Order) { /* ... */ }
}

namespace Ecommerce.InfrastructureLayer.Mailers;

public class OrderConfirmationAwsSesMailer : IOrderConfirmationMailer
{
    public OrderConfirmationAwsSesMailer(/* ... */) { /* ... */ }

    public Task Send(Order order) { /* ... */ }
}

Like mentioned before, everything can be wired together via dependency injection or some other form of bootstrapping. Most frameworks have their own way of resolving dependencies and instantiating service objects like these; in order to execute them as a result of requests from consumers (e.g. a CLI command, a web request, the click of a button). In essence, it’s something like this:

var repository = new OrderRepository(dbContext);
var mailer = new OrderConfirmationAwsSesMailer(mailerConfig);
var paymentGateway = new AuthorizeNetPaymentGateway(paymentConfig);

var orderCreator = new OrderCreator(repository, mailer, paymentGateway);

orderCreator.Run(payload);

So, the ports and adapters architectural pattern has a business logic layer which has no dependencies on any other components outside of itself. It defines a set of interfaces for all external components that want to interact with it. It also has an infrastructure layer which implements concrete classes for the domain layer’s interfaces. Data access, interaction with external services, user interface, and presentation logic all live here. And finally, it has a service/application layer which, similar to its counterpart from the layered architecture, can emerge between the business logic and infrastructure layers when needed to expose a set of procedures that closely map to user interface actions. It exposes all the business operations that the system supports and orchestrates the business logic to carry them out.

When organizing the code following the the ports and adapters architectural pattern, the business logic layer defines interfaces/ports, which the infrastructure layer implements concrete objects for. These objects take care of interacting with the external world.

Clean architecture, onion architecture and hexagonal architecture are all different names for the same core concepts and principles espoused by ports and adapters; sometimes with slight variations depending on the particular flavor and tech stack.

Command query responsibility segregation

The command query responsibility segregation pattern (CQRS) builds on the principles from ports and adapters and adds support for multiple different representations of the system’s data. That is, having multiple persistence models for the same data set. One of the most common examples is a system that stores and operates on day to day business transactions using an OLTP (online transaction processing) representation, but also needs to provide an OLAP (online analytical processing) data warehouse for high level business analysis. One ground-truth source of data (the OLTP) is used to produce additional representations with a different schema (the OLAP). CQRS enables this.

As such, CQRS is ideal for event sourced domain models, because it allows persisting the many projections of an aggregate’s data into their own databases. (Remember that in the context of event sourcing, a projection is a representation of the state of a business entity which is constructed based on its stored domain events). It allows of course, querying of these projections with much more flexibility than what a pure event store allows on its own.

At the core of CQRS there are two types of models: a command execution model (the C in CQRS) and one or many read, or query, models (the Q in CQRS). In database terms, this is similar to a primary-replica type of situation, where the command execution model represents the primary, and the read models represent the replicas.

CQRS exposes two types of models, one for executing commands and many others for reading. In the backend, a projection engine keeps the read models up to date with the latest changes from the command execution model.

The command execution model is the system’s source of truth, whose data is strongly consistent. It’s the one used to execute and record business operations, and enforce business rules and invariants. All operations that result in changes to the system state are handled here.

The query, or read, models take care of exposing different projections of the system state. These are read-only models that are meant for presenting the system’s data to its consumers. They are generated based on the main data source, which is the data maintained in the command execution model. In fact, read models should be capable of being easily destroyed and recreated from the main data.

Read models are generated using components that we call projection engines, which can work synchronously or asynchronously when fetching data from the command execution model to generate their projections.

Synchronously, projection engines generate read models using a catch-up subscription design. It works like this:

The projection engine determines the last query checkpoint. Basically, when was the last time it read the main database.
The projection engine queries the main database and identifies newly added and updated records since the last query checkpoint.
The projection engine uses the new data to regenerate or update the read model.
The projection engine updates the latest query checkpoint, to be used during the next execution of the engine, starting again at step 1.

Synchronous projection engine.

This checkpoint can be implemented in various ways. The main idea is to offer a mechanism for the projection engine to be able to tell which records are new or have changed since its last run. One way to do it is using something akin to SQL Server’s rowversion feature. This is a database-wide, auto-incrementing numeric value that increases after every INSERT and UPDATE operation. The newly incremented value is assigned to the rows that were added or updated. With this, the projection engine can easily query all records whose rowversion is greater than the last checkpoint. Similar functionality can be implemented using database triggers too. Or database tables can also include timestamp fields that indicate when records were last touched.

Asynchronous projection engines on the other hand, rely on the command execution model publishing all changes to a message bus. The projection engine can subscribe to these messages and update its read model as they come. This method, while scalable, comes with drawbacks inherent to distributed computing like handling duplicates and out of order messages. It’s also more difficult to destroy and regenerate read models that rely on asynchronous messaging only, since the messages are gone after they are processed. Often the better solution is to use a synchronous design and then, only if needed, augment it with the asynchrony.

Naturally, CQRS is ideal when the system needs to support different types of databases. Imagine an online store, for example, which has an inventory management component that works directly with the command execution model backed by a relational database. But for displaying the product catalog to users, it uses a read model backed by a search index, optimized for full text search. And for event sourced domain models, CQRS is practically mandatory.

Scope

The patterns that we’ve seen in this section are not exclusively meant as system-wide nor even bounded-context-wide organizational principles. Arbitrarily enforcing a single pattern everywhere often leads to accidental complexity. Instead we should follow DDD’s core principles and deploy these strategies according to what the business domain necessitates. Indeed, within a bounded context, especially one that deals with many subdomains, there should be logical separation between these subdomains. Each resulting module could use a different architectural pattern. In other words, these patterns divide the code base into horizontal slices; and the subdomains can be used to define the vertical slices. This way, a monolithic bounded context can be modularized. This leaves the code base in a good position for future refactoring and further physical separation into distinct bounded contexts in the future (i.e. into separate applications, services and/or processes).

When needed, different architectural patterns can be deployed to different subdomains within the same bounded context.

Section 9: Communication patterns

In the last few sections we’ve discussed how to implement business logic and how to leverage architectural patterns to organize the code within a bounded context. In this section, we will take a higher level view and go beyond the scope of a single bounded context. We will learn about patterns of communication across bounded contexts. In other words, how to integrate them.

Model translation

Back when we talked about integrating bounded contexts, we discussed how they can use different communication strategies depending on the disposition of the teams that own them. When the teams have strong communication, cooperation patterns like partnership and shared kernel can be used for integration. Here, bounded contexts can communicate without friction. The protocols for doing so are defined by the teams in an ad-hoc manner and development moves forward without too many issues.

However, when the teams are not closely aligned, and cooperation patterns are impossible, a customer-supplier relationship emerges. This can be addressed by implementing an anticorruption layer in the downstream consumer, to adapt the upstream supplier’s model to the consumer’s needs. Another option is for the upstream supplier to implement an open-host service and expose an integration-specific published language, which isolates consumers from the details of its internal model. Both approaches are meant to protect a bounded context’s model from the influence of external models.

In these non-cooperation cases, we have to be more intentional in how we design the communication between bounded contexts, and the need for a translation of their models/languages arises. This logic that translates the models can either be stateless or stateful.

Stateless model translation

Stateless model translation can happen on the fly via the proxy design pattern. The idea is to put an intermediary component in place, which receives messages in one language, translates them, and forwards them to their destination.

If the proxy is implemented by the consumer or downstream component, functioning as an anticorruption layer, then it intercepts outgoing requests and translates them to a language that the upstream supplier can understand. It does the same with the incoming responses from upstream: it translates them to a language that the consumer can understand.

If the proxy is implemented by the supplier or upstream component, it functions as an open-host service. It takes the incoming requests that arrive using the published language and translates them to the supplier’s internal one. Then, outgoing responses get translated to the published language.

In essence, a proxy is nothing more than a component that sits between two other components and translates the messages passing between them.

These proxies can be synchronous or asynchronous.

Synchronous translation is straightforward. Messages are translated just as they are being received or sent, depending on whether the translation happens upstream or downstream. Normally, the translation logic is implemented directly in the bounded context that needs it.

In some cases though, it makes sense to separate it into its own independent component, implementing an API gateway pattern. Sometimes, off the shelf software or cloud services like KrakenD or AWS API Gateway can be used to implement them.

Having a separate API gateway has some advantages, other than the obvious decoupling of model translation logic from actual business logic. It can make it easier to expose multiple versions of the API. That is, of the published language. It can also be consumed by multiple downstream components, making it essentially an integration-specific bounded context. We call these, interchange contexts.

When extracted into its own component, a proxy becomes an API gateway. This is useful for further separation of concerns, offering multiple versions of the API’s published language, and serving multiple consumers.

Asynchronous translation on the other hand, is not direct. It relies on an event driven design to implement a message proxy; which subscribes to events published by one bounded context, translates them, and forwards them to their destination.

The proxy can also apply filtering to the messages, deciding which ones to forward and which ones to ignore. This is useful, for example, to keep the published language free of domain events that are meant to be internal to the bounded context that produces them.

An asynchronous proxy listens to events in one language and translates them to another language.

Stateful model translation

Stateful model translation comes into play when more complex translation logic that requires persistent storage is needed. This is useful for two common scenarios: when the requests need to be aggregated, and when data from multiple sources needs to be unified. In both cases the component doing the translation needs to keep track of the incoming requests and messages. It stores them in a database in order to reconstruct them eventually.

Data aggregation may be needed for performance reasons when, for example, multiple requests need to be collected together and dispatched as one batch. Another case is when multiple disparate messages need to be combined into one single bigger message that conveys more complete information. This can work both synchronously and asynchronously. That is, the messages can be direct requests or published events.

An API gateway on its own is not appropriate for this type of model translation, as it doesn’t provide persistent storage or more complex processing logic beyond mapping and rerouting. Instead, it can be implemented from scratch as a bespoke solution, or leveraging off the shelf stream processing platforms like Apache Kafka or AWS Kinesis.

A proxy can aggregate and/or combine multiple separate messages into a single one for performance and consolidation purposes.

The unification of multiple data sources is also a common use case for stateful model translation. This is necessary for example when a component needs to process data from many different upstream suppliers and apply complex business logic to it. This is commonly seen in the backend for frontend pattern. In this pattern, an API is defined to meet all of a frontend’s needs, while serving as a facade for a number of backend services. This allows the frontend to call a single backend to interact with all the various services it may need.

Integrating aggregates

Before, we talked about the rules that we follow to limit the scope of aggregates and ensure they encapsulate a coherent set of business logic. We strive to keep them focused, with tight boundaries. They represent strong data consistency and transactional boundaries. That is, they should only contain strongly consistent data and the system’s transactions should be limited to a single aggregate instance. It is also true however, that there are business processes that involve multiple aggregates. The following patterns allow us to implement such business processes without breaking the aggregates’ isolation rules.

Outbox

As we know, along with commands, domain events are part of an aggregate’s public interface. By publishing domain events to a message bus, aggregates communicate with the outside world. Or more specifically, to their subscribers, who listen to these events in order to trigger their own logic. The outbox pattern allows aggregates to reliably publish domain events.

The outbox pattern works by storing domain events in the same database as the aggregate’s data. Leveraging database transactions to ensure both the state changes and the events are saved atomically. The process is this:

Aggregate state changes and new events are committed in the same database transaction.
The message relay picks up the new events from the database.
The message relay publishes the new events to the message bus.
After successful publishing, the message relay marks the event as such, or deletes it.

The outbox pattern is about storing an aggregate’s domain events in a database, making sure to commit them in the same transaction as state changes.

Saga

A saga leverages the reliable publishing of domain events afforded to us by the outbox pattern to implement business processes that span multiple aggregates. They do this by listening to events and responding to them by issuing commands to relevant components. A saga represents a long-running business process. One that spans multiple transactions.

Sagas can vary in complexity. Sometimes it is enough to respond to events by directly issuing commands from the saga itself.

public class OrderProcessingSaga
{
    private readonly IOrderRepository _orderRepository;
    private readonly IPaymentService _paymentService;
    private readonly IInventoryService _inventoryService;
    private readonly IShippingService _shippingService;

    //...

    // These event handler methods all follow a similar pattern:
    // Receive the event, then call the corresponding command.
    public void Process(OrderCaptured @event)
    {
        var order = _orderRepository.Fetch(@event.OrderId);

        _paymentService.ProcessPayment(order);
    }

    public void Process(PaymentAccepted @event)
    {
        var order = _orderRepository.Fetch(@event.OrderId);

        _inventoryService.PreparePackage(order);

        order.UpdateStatus(@event.NewOrderStatus);
        _orderRepository.Save(order);
    }

    public void Process(InventoryCleared @event)
    {
        var order = _orderRepository.Fetch(@event.OrderId);

        _shippingService.ScheduleDelivery(order);

        order.UpdateStatus(@event.NewOrderStatus);
        _orderRepository.Save(order);
    }

    public void Process(ShipmentDispatched @event)
    {
        var order = _orderRepository.Fetch(@event.OrderId);

        order.UpdateStatus(@event.NewOrderStatus);
        _orderRepository.Save(order);
    }
}

Other times, a saga needs to keep its own state. For example, when the saga needs to track received events; to react to certain failure conditions; issue retries, etc. In these cases, the saga can be implemented as an event sourced aggregate, keep a record of all received events, and publish events of its own that contain the commands that it wants to execute. Then, a separate message relay component should be listening to the saga’s events and run the commands contained within.

public class OrderProcessingSaga
{
    // Like any other event sourced aggregate, this saga stores its list of
    // events.
    private readonly IList<DomainEvent> _events = [];

    // ...

    // These event handlers all also follow a similar pattern. Instead of
    // directly calling the commands though, they register an event with the
    // necessary information for the message relay to call the commands.
    public void Process(OrderCaptured @event)
    {
        // ...

        _events.Append(@event);
        _events.Append(new CommandIssuedEvent(
            target: Target.PaymentService,
            command: new ProcessPaymentCommand(@event.OrderId)
        ));
    }

    public void Process(PaymentAccepted @event)
    {
        // ...

        _events.Append(@event);
        _events.Append(new CommandIssuedEvent(
            target: Target.InventoryService,
            command: new PreparePackageCommand(@event.OrderId)
        ));
    }

    public void Process(InventoryCleared @event)
    {
        // ...

        _events.Append(@event);
        _events.Append(new CommandIssuedEvent(
            target: Target.ShippingService,
            command: new ScheduleDeliveryCommand(@event.OrderId)
        ));
    }

    public void Process(ShipmentDispatched @event)
    {
        // ...

        _events.Append(@event);
    }
}

Sagas represent a long running business process. One that spans many transactions. They receive events and invoke commands as a result.

Always remember though, sagas make it possible to implement business processes that span multiple aggregates, but the data across aggregates is only eventually consistent. The core aggregate design rules still apply: only the data within an aggregate is strongly consistent.

Process manager

The process manager pattern is essentially a more complex saga. While sagas mostly deal with linear flows, and direct mapping between events and commands; a process manager implements more complex business logic that keeps track of the sequence of events, has its own state, and determines how to react. It does not only have a simple mapping of events to commands. Instead it has complex logic that decides how to respond to incoming events. It is a central processing unit, listening to events from and issuing commands to multiple sources, and managing an overall business process.

Another difference between them is that sagas are instantiated implicitly, while process managers are instantiated explicitly. Meaning that sagas live and die within the context of the events that they listen to. They “get activated” when an event that they are interested in is published. Process managers on the other hand get activated when the business process they manage gets initiated. They stay alive through the duration of the process’s many steps.

Implementation wise, they are essentially aggregates with a strong focus on responding to events. They have their own persistent state, explicit identity, lifecycle, and related objects; as well as a series of event handlers, just like a saga would have.

A process manager orchestrates a long running business process with complex logic that involves many components. The application layer instantiates them explicitly, as it would any other aggregate.

public class OrderProcessManager
{
    private readonly IList<DomainEvent> _events = [];

    // Process managers have their own explicit identity. They are very similar
    // to aggregates or entities.
    private OrderId _id;

    // They can include other properties to track state as needed.

    // ...

    // Process managers usually include an initialization procedure that kicks
    // off the process, and provides the necessary parameters.
    public void Initialize(/* ... */)
    {
        // ...

        _events.Append(orderProcessingInitiated);
        _events.Append(new CommandIssuedEvent(
            target: Target.PaymentService,
            command: new ProcessPaymentCommand(@event.OrderId)
        ));
    }

    // The event handlers are very similar to those of the event sourced
    // stateful saga. The difference is that here they run more complex logic to
    // determine how to continue the process. As opposed to the saga's simpler
    // mapping of incoming events to commands.
    public void Process(PaymentAccepted @event)
    {
        // ...

        _events.Append(@event);
        _events.Append(new CommandIssuedEvent(
            target: Target.InventoryService,
            command: new PreparePackageCommand(@event.OrderId)
        ));
    }

    public void Process(InventoryCleared @event)
    {
        // ...

        _events.Append(@event);
        _events.Append(new CommandIssuedEvent(
            target: Target.ShippingService,
            command: new ScheduleDeliveryCommand(@event.OrderId)
        ));
    }

    public void Process(ShipmentDispatched @event)
    {
        // ...

        _events.Append(@event);
    }
}

Architectural patterns to use within bounded contexts

These are the main concepts around the architectural patterns that we’ve discussed.

Patterns for communicating across bounded contexts

These are the main concepts around the communication patterns that we’ve discussed.

Implementing business logic with Domain-Driven Design

2026-04-21T00:00:00+00:00

Photo by Bimal Gharti Magar, 2026.

This is part 2 of a series of blog posts on Domain-Driven Design:

High level system analysis and design with Domain-Driven Design

Implementing business logic with Domain-Driven Design

Designing software architecture with Domain-Driven Design

Applying Domain-Driven Design in Practice

As a result, DDD offers a treasure trove of concepts, patterns and tools that can be applied to any software project, regardless of the size and complexity.

Implementing business logic with Domain-Driven Design

Section 5: Implementing simple business logic

Now that we’ve explored DDD’s higher level system design concepts, it’s time to zoom in and start looking at how to implement business logic: the most important part of software. We will start by discussing two patterns that are ideal for implementing simple business logic: transaction script and active record.

Transaction script

According to Martin Fowler, the transaction script pattern “organizes business logic by procedures where each procedure handles a single request from the presentation.”

For most programmers that have experience with procedural languages, the transaction script is easy to grasp. This pattern is about conceptualizing a system as a collection of transactions. And organizing these transactions as independent, transactional procedural scripts. Think one transaction script per use case, exposed for the users to invoke when they need to.

The core idea of transaction script is about putting business transactions front and center. Closely related scripts can be implemented as methods in a service class. Or you could also have a separate “service object” class for each script.

Indeed, on its own, the transaction script pattern is a simple way of organizing relatively simple domain logic. However, as we’ll see throughout the next few sections, it is also a foundational pattern that is present when implementing the more advanced ones. Also, even though the concept is simple, implementation of transaction script in the real world has to be done carefully, in order to avoid falling into common pitfalls, often related to ensuring atomicity.

class AddItemToQuote
{
    // ...

    // This method adds a new item to a shopping cart and records the operation
    // into a log table. Both operations are done separately.
    public void Run(int quoteId, int productId, int quantity)
    {
        _db.ExecuteSql($"""
            INSERT INTO quote_items(quote_id, product_id, quantity)
            VALUES ({quoteId}, {productId}, {quantity});
        """);

        // If some error happens after the previous command and before the one
        // below, the system will be left in an inconsistent state. The new item
        // would have been added to the shopping cart, but the audit log would
        // not have a corresponding event.

        _db.ExecuteSql($"""
            INSERT INTO quote_audit_log(
                quote_id, event_description, date_created
            )
            VALUES ({quoteId}, 'Item added to quote', CURRENT_DATE);
        """);
    }
}

That is, a transaction script needs to actually be transactional. It needs to be atomic. Of course, each domain’s requirements will dictate how true this is, but in general, we want transaction scripts to operate as a unit, and make sure that they don’t leave the system in an inconsistent state in situations when the script fails midway through its execution.

If all the script does is interact with a relational database, it is easy to address this issue. The solution is to perform the operations within a database transaction:

class AddItemToQuoteWithTransaction
{
    // ...

    public void Run(int quoteId, int productId, int quantity)
    {
        try
        {
            // We can use a database transaction to fix the issue.
            _db.BeginTransaction();

            _db.ExecuteSql($"""
                INSERT INTO quote_items(quote_id, product_id, quantity)
                VALUES ({quoteId}, {productId}, {quantity});
            """);

            _db.ExecuteSql($"""
                INSERT INTO quote_audit_log(
                    quote_id, event_description, date_created
                )
                VALUES ({quoteId}, 'Item added to quote', CURRENT_DATE);
            """);

            _db.CommitTransaction();
        }
        catch
        {
            _db.RollbackTransaction();
            throw;
        }
    }
}

The problem gets more complicated when the script performs a distributed transaction. That is, when it interacts with other systems which are outside of the scope of a relational database transaction. For example, interacting with the file system, or with an external web service.

class AddItemToQuoteWithDistributedTransaction
{
    // ...

    public void Run(int quoteId, int productId, int quantity)
    {
        _db.ExecuteSql($"""
            INSERT INTO quote_items(quote_id, product_id, quantity)
            VALUES ({quoteId}, {productId}, {quantity});
        """);

        // We're back to our initial problem. Any failure at this point in the
        // script will have updated the shopping cart without having sent the
        // notification to the external system.

        _api.NotifyQuoteItemAdded(quoteId, productId, quantity);
    }
}

These are hard to deal with and often require very particular code to handle properly. Further in this series we’ll discuss this topic again when we talk about CQRS and the outbox pattern.

Sometimes though, the distributed transaction is not as obvious. Consider a web application that exposes an endpoint to increment the quantity of particular shopping cart items by one:

class IncrementQuoteItemQuantity
{
    // ...

    public void Run(int quoteItemId)
    {
        _db.ExecuteSql($"""
            UPDATE quote_items
            SET quantity = quantity + 1
            WHERE id = {quoteItemId};
        """);
    }
}

Even though that’s a single database operation, there is inter-system communication between the user’s browser and the application server; and between the application server and the database. A network outage, for example, that happens in the middle of this operation can leave the system in an inconsistent state. If it fails after it’s already submitted the UPDATE command to the database, and responds with a failure message to the client, the client might attempt to try and increase the quantity again. This would result in the increment being done two times, when actually it should have been only one.

In the context of client-server applications, some transactions are distributed even though at first glance they might not seem that way. In this simple operation, there are three systems interacting over the network: The client, the application server and the database.

There are two possible ways of handling this type of situation: making the operation idempotent, or using optimistic concurrency control.

One way to make the operation idempotent, that is, to make sure that it always produces the same results, no matter how many times it’s done, is to have the caller specify the quantity to update the item to. That is, changing the operation from “add one quantity”, to “set the quantity to this”. Like so:

class IncrementQuoteItemQuantityIdempotent
{
    // ...

    public void Run(int quoteItemId, int quantity)
    {
        _db.ExecuteSql($"""
            UPDATE quote_items
            SET quantity = {quantity}
            WHERE id = {quoteItemId};
        """);
    }
}

On the other hand, implementing optimistic concurrency control in this scenario could be done by effectuating the record update while using the current state of the record when checking for a match. This boils down to including the expected values of the different fields in the WHERE clause. This way, the record will be updated only if it is in the state that the caller expected it to be:

class IncrementQuoteItemQuantityOptimisticConcurrency
{
    // ...

    public void Run(int quoteItemId, int quantity)
    {
        _db.ExecuteSql($"""
            UPDATE quote_items
            SET quantity = quantity + 1
            WHERE id = {quoteItemId} AND quantity = {quantity};
        """);
    }
}

In both cases, the caller would have to obtain the current state of the record before attempting the update operation.

Active record

Martin Fowler describes the active record pattern as “an object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.”

The main advantage of the active record pattern is that it greatly simplifies database access. Especially when leveraging ORM frameworks. With active record, you usually end up with a set of classes that closely mirror your database structure. You have one class per table, where the fields of those classes represent table columns and the instances of those classes represent individual records in those tables.

So, when the underlying data model is complex, business logic organized in transaction scripts can be augmented with active record to reduce a great deal of the complexity involved in database interactions. This is because the active record pattern takes care of mapping between database records and in-memory objects, as well as all the data retrieval and manipulation commands (I.e. the CRUD). This allows the transaction scripts to focus more on domain logic, and less on manipulating the underlying data.

class AddItemToQuoteActiveRecord
{
    // ...

    public void Run(int quoteId, int productId, int quantity)
    {
        // Active record allows us to work with objects instead of directly
        // issuing database commands.
        var item = new QuoteItem
        {
            QuoteId = quoteId,
            ProductId = productId,
            Quantity = quantity
        };

        item.Save();
    }
}

Of course, active records can (and should) also include domain logic. Aspects like the relationships between the domain entities, validation, complex database queries, and even the business procedures that involve them are all part of an active record object.

# This class is an Order active record. It establishes relationships with other
# entities, defines basic validation rules, and has custom queries.
class Order <  ApplicationRecord
    self.table_name = "orders"

    enum :status, [ :pending, :paid, :shipped, :cancelled ]
    enum :payment_method, [ :cash, :credit_card, :transfer ]

    has_many :order_items
    has_one :shipping_address
    has_one :billing_address

    validates :email, presence: true, email: {mode: :strict}
    validates :phone, length: {minimum: 10, allow_blank: true}

    scope :sorted, -> { order(created_at: :desc) }
    scope :new_ones, -> { where("created_at >= ?", 1.day.ago) }
    scope :have_phone, -> { where.not(phone: nil) }
    scope :where_email_is, ->(email) { where("lower(email) = ?", email.downcase) }
end

# The framework augments it with data access logic, like querying:
order = Order.find(123)
expensive_items = order.order_items.where("price >= ?", 200)
orders_from_us = Order.where(country_code: "US")
new_orders = Order.new_ones.sorted

# ...and making changes:
new_order = Order.new(email: "test@email.com")
new_order.save

order.update(
    shipping_number: "1234567890",
    status: :shipped
)

The Active Record framework from Ruby on Rails is a great implementation of the pattern that puts business logic in a centralized location while magically extending the objects with all the data access logic they need.

This is a big step up from raw transaction scripts, but still it has its own disadvantages. First, the active records can end up having too much responsibility, and grow to unmanageable sizes, especially for core business entities. Second, the active record pattern by itself does not enforce access control on its properties. Meaning that external processes can freely modify their state, potentially ignoring any business rules that could bind them.

Something else to be aware of is that when active records define little to no behavior, that is, when they don’t implement business logic, they become an anemic domain model. Active record objects that focus only on database access tasks, and higher level “service objects” that manipulate them and implement all the domain logic themselves are the hallmark of anemic domain models.

An anemic domain model may look like a full fledged domain model, with all the objects representing domain concepts and their relationships, but they are hollow. Their most important part is missing. In the next section we will see what a real domain model looks like, DDD’s definitive pattern for implementing business logic in complex subdomains.

When to use them

In some circles, the transaction script and active record patterns are considered anti patterns. But really, they are just tools for the job. When misapplied, they become detrimental, but when used to solve the problems they are good at, they shine. In fact, they can give you a lot of bang for your design buck. But when the domain logic you’re implementing is very complex, they can begin to fall short, as their relatively low level of abstraction becomes insufficient and prone to code repetition, and inconsistencies when this repeated code goes out of sync. Which is a big problem when dealing with complex subdomains.

Section 6: Tackling complex business logic

When implementing complex business logic, the patterns that we’ve seen up to this point can only get you so far. They start to leave a lot to be desired due to their relatively low level of abstraction. When the situation calls for a higher level of abstraction, in order to produce a more supple design, DDD calls for the domain model pattern.

Domain model

Taking from Martin Fowler’s definition, we learn that the domain model is a full object-oriented model of the domain, that incorporates both behavior and data. Domain models take the form of a large web of interconnected objects, where each one represents a meaningful concept in the business domain.

In his book, Eric Evans expanded greatly on this definition, introducing a set of patterns and tools for implementing domain models. Indeed, to build a domain model, we incorporate other building block patterns: value objects, entities, aggregates, domain events, domain services.

Also, there are two main rules that a domain model needs to follow:

There should be no dependency on particular frameworks or infrastructure. Objects in the domain model should be plain old objects, focused only on domain logic.
The domain model should speak the ubiquitous language of the bounded context in which it operates. That means that all identifiers should call back to business concepts and it should represent the mental model of the domain experts.

Value object

A value object is an object whose identity is given by its properties. That is, its value. It does not have an explicit identifier, like an Id field. Consider for example a Point object:

class Point
{
    double _x;
    double _y;
}

The X and Y values completely define a point. Two instances of this class with the same X and Y coordinates represent the same point. Changing the value of either coordinate produces a new point.

They are useful for representing properties of other objects and are usually implemented as immutable objects. One of the great strengths of value objects is that they allow the model to speak the ubiquitous language by replacing primitives with bespoke small objects that make the code clearer and encapsulate related business logic.

As an example, consider this Order class.

class Order
{
    private int _id;
    private string _status;
    private string _email;
    private string _phone;
    private double _shippingWeight;
    private string _countryCode;

    public Order(/*...*/) {/*...*/}
}

// This class can be instantiated like this:
var order = new Order(
    id: 12345,
    status: "Processing",
    email: "test@email.com",
    phone: "123-456-7890",
    shippingWeight: 10,
    countryCode: "US"
);

Here, all the values are assigned by convention. An email, a phone number, a status… They are all just strings with no special behavior or meaning. We must know what they look like beforehand in order to assign them correctly.

If we use value objects, this class could be implemented like this instead:

class Order
{
    private OrderId _id;
    private OrderStatus _status;
    private PersonName _name;
    private EmailAddress _email;
    private PhoneNumber _phone;
    private Weight _shippingWeight;
    private CountryCode _country;

    public Order(/*...*/) {/*...*/}
}

// Now, instances can be created like this:
var order = new Order(
    id: new OrderId(12345),
    status: OrderStatus.Processing,
    name: new PersonName("Kevin", "Campusano"),
    email: EmailAddress.Parse("test@email.com"),
    phone: PhoneNumber.Parse("1234567890"),
    shippingWeight: Weight.FromLbs(10.25),
    country: CountryCode.Parse("US")
);

This approach has many advantages:

First of all the Order class does not have to validate its fields. Validation can happen in the value objects. This is good because it allows other domain objects to have fields of the same type without having to duplicate the validation logic themselves. Imagine you also have a contact object somewhere in your model that includes a phone number field, for example. Both it and Order can reuse the phone number value object, and the logic it carries.

Secondly, value objects can capture the business logic that’s closely related to them. A phone number field, for example can implement methods to obtain further information about it like its area code or the country it belongs to. A “weight” value object can implement logic for converting from one measuring system to another.

// Here's a weight value object that encapsulates logic like converting from one
// unit to another and comparing the magnitude of different values.
class Weight : IComparable<Weight>, IEquatable<Weight>
{
    const double LbsPerKg = 2.20462;

    double _lbs;

    private Weight(double lbs) { _lbs = lbs; }

    public static Weight FromLbs(double lbs) => new Weight(lbs);
    public static Weight FromKgs(double kgs) => new Weight(kgs * LbsPerKg);

    public double ToLbs() => _lbs;
    public double ToKgs() => _lbs / LbsPerKg;

    public int CompareTo(Weight? other) => ToLbs().CompareTo(other?.ToLbs());
    public bool Equals(Weight? other) => ToLbs().Equals(other?.ToLbs());
}

Finally, using value objects lets the model speak the ubiquitous language, and thus makes it clearer. Strongly typing properties in this way, beyond just using language primitives, very clearly captures the intent of the property.

Entities

Entities are objects that represent the concepts in the domain that have a lifecycle and explicit identification. A person, an order, a lead, a transaction. These are all examples of entities. Entities, as opposed to value objects, are not immutable, and are expected to change throughout their life in the system. Value objects, like we saw before, are ideal for representing properties of entities.

Entities are a core building block for a domain model. However, they are not used independently. They are used as part of an aggregate.

Aggregates

An aggregate is a hierarchy of entities and value objects that are bound together by closely related business logic. The aggregate forms a boundary that protects the consistency of the objects that compose it. It achieves this by preventing external objects from directly modifying its state and defining a public interface through which other parts of the system can interact with it.

The rest of the system cannot directly mutate the state of the entities within an aggregate. They can only do so via the methods exposed by the aggregate’s public interface. These methods, so called commands, encapsulate the aggregate’s business logic and protect them from corruption, by enforcing the necessary validations and invariants. Indeed, all the business logic that’s closely related to the aggregate lives in one place: the aggregate itself.

// Here we have an aggregate that represents a shopping cart and its items.
public class Quote
{
    // It does not expose its list of items publicly. Instead, it implements
    // public methods for manipulating them.
    IList<QuoteItem> _items = [];

    QuoteItem? GetItemBy(ProductId productId) =>
        _items.FirstOrDefault(i => i.ProductId == productId);

    public void AddItem(ProductId productId, int quantity)
    {
        var item = GetItemBy(productId);

        if (item != null)
            throw new InvalidOperationException("Item already exists.");

        _items.Add(new QuoteItem
        {
            ProductId = productId,
            Quantity = quantity
        });
    }

    // Even though this method modifies an item, and not the quote itself, it's
    // still implemented here, because this is the aggregate root.
    public void SetItemQuantity(ProductId productId, int quantity)
    {
        var item = GetItemBy(productId) ??
            throw new InvalidOperationException("Item does not exist.");

        item.Quantity = quantity;
    }

    // ...
}

These commands, which are the public interface of an aggregate, should all be defined in a single entity within the aggregate. We call this entity the aggregate root. If the aggregate is a hierarchy of objects, and we can picture it as a tree, then the root is the object that exists at the root of the tree, where all branches come from.

The aggregate is a hierarchy of objects. The aggregate root is the sole object in this hierarchy with which other components interact.

This focus on commands makes the implementation of the application layer components more straightforward. I.e. they become transaction scripts. By “application layer components”, I mean those components that orchestrate calls to the domain model in order to fulfill use cases in response to, say, user requests. They follow a general pattern of:

Load the aggregate. Typically from persistent storage.
Invoke the desired command.
Persist the new state of the aggregate.

For example:

// Here's an application service leveraging the quote aggregate to add an item
// to a shopping cart.
class AddItemToQuote
{
    // ...

    public Result Run(QuoteId quoteId, ProductId productId, int quantity)
    {
        try
        {
            var quote = _quoteRepository.FindById(quoteId);
            if (quote == null) return Result.Error("Quote not found.");

            quote.AddItem(productId, quantity);

            _quoteRepository.Save(quote);

            return Result.Success();
        }
        // Notice how the application layer logic takes care of database related
        // errors. Remember that the aggregate is a plain old object which has
        // no knowledge about infrastructure or frameworks. The data access
        // logic, in this case encapsulated in the _quoteRepository, is the one
        // that will produce such errors when trying to commit changes to the
        // underlying storage.
        catch (ConcurrencyException ex)
        {
            return Result.Error(ex);
        }
    }
}

There are other rules that aggregates need to follow. One of them is that the aggregate acts as a transaction boundary for aggregate operations. That is, all changes to an aggregate should be transactional, atomic. Also, no system operation should involve a transaction that includes different aggregates. We should have one aggregate per database transaction.

This reveals another aspect of aggregates: An aggregate should expect strong consistency only on its own objects. For objects that are outside of the aggregate, eventual consistency should suffice. Or, looking at it from a different angle, this means that when designing an aggregate, data consistency is a guiding principle. The data that needs to be strongly consistent in order to fulfill the business requirements, should be included in the aggregate. The data that can be eventually consistent and still meet the requirements, probably belongs in a different aggregate.

At first glance, all these rules for aggregates may seem overly limiting. But the main idea is to keep their scope as constrained as possible, to prevent them from growing too much and taking on too many responsibilities. We should strive to keep aggregates small, highly cohesive, and decoupled from other system components. That unlocks the ability for them to be reorganized and reused in many ways. This helps avoid code duplication when fulfilling the requirements of today while also reducing the cost of evolving to meet the requirements of tomorrow.

Domain event

Through their commands, the outside world can send messages to aggregates. Domain events are the mechanism through which aggregates can themselves send messages to the outside world. As their name suggests, domain events are messages that describe important events that have happened in the business domain, related to an aggregate. Think “order placed”, “user registered” or “product out of stock”. The events should provide all necessary data that allows consumers to understand what has happened.

// This JSON data describes the event of an item being added to a shopping cart.
// It includes all the details that subscribers need to know about the event.
{
    "quote-id": "f3774200-9e57-4ad2-9d93-ffb9e92b8364",
    "event-id": 123,
    "event-type": "item-added-to-quote",
    "event-time": 1628970815,
    "product-id": "7e7aee52-9aa1-4e0e-810e-666cedab5a7a",
    "quantity": 1
}

public class Quote
{
    // ...

    IList<DomainEvent> _domainEvents = [];

    public void AddItem(ProductId productId, int quantity)
    {
        // ...

        // This command creates the event and adds it to the aggregate's list.
        _domainEvents.Add(new ItemAddedToQuote(
            quoteId: _id,
            productId: productId,
            quantity: quantity
        ));
    }
}

Domain events are also part of an aggregate’s public interface. Just like its commands. Other parts of the system can subscribe to these events, and when they happen, react accordingly. We will learn more about domain events, and see how to push them to subscribers, later in the series.

Domain service

Sometimes there’s business logic that doesn’t belong to a particular aggregate or value object, or that involves multiple aggregates. Domain services can be implemented in these cases. Domain services are simple stateless objects that implement some business logic. Somewhat like an aggregate’s command, but defined outside of an aggregate.

// Domain services are a good solution for implementing logic that orchestrates
// calls to different system components.
class PlaceOrder
{
    // ...

    public Result Run(QuoteId quoteId)
    {
        try
        {
            var quote = _quoteRepository.FindById(quoteId);
            if (quote == null) return Result.Error("Quote not found.");

            quote.Close();
            _quoteRepository.Save(quote);

            var order = new Order(quote);
            order.PlaceOrder();
            _orderRepository.Save(order);

            // We can imagine the above code producing an "order placed" event,
            // and a separate payment processing component picking it up and
            // getting to work. Then, inventory and shipping components could
            // continue processing the order after the payment is successful.

            return Result.Success();
        }
        catch (ConcurrencyException ex)
        {
            return Result.Error(ex);
        }
    }
}

Of course, the rule of “modify only one aggregate per transaction” still applies. Even for domain services that orchestrate business operations that involve multiple aggregates. Remember, if strong consistency is needed across separate aggregates, and thus they have operations that need to be executed within the same transaction, then maybe these objects should be part of the same aggregate in the first place.

It’s also important to consider domain services as a sort of last resort. A final domain modeling tool to use only when the other tools like aggregates, value objects, commands and domain events, fall short and truly can’t meet the requirements on their own.

Data access concerns

As we’ve stated at the beginning, the domain model should be made of plain old objects. That means no dependency on framework components or particular infrastructure, just pure domain logic. Data access logic is one of those things that it should be oblivious about.

In practical terms, your choice of technology stack and software development framework will usually dictate the mechanisms you use for interacting with persistent data storage. But that doesn’t matter to the domain model, with the correct abstraction, it should be compatible with any data access mechanism. Here are a few patterns worth mentioning:

We’ve already seen active record being used as a data access strategy. Particularly useful when paired with an ORM framework. Due to its nature of tieing infrastructure concerns (i.e. data access logic) with the business logic, you have to jump through some hoops to make it work with a domain model. But it can be done. The repository pattern is also a good fit for solving the data access problem in the context of DDD. It offers a clear, intention-revealing interface for data retrieval and modification. Unit of work is also a pattern worth looking into, for coordinating numerous database operations.

But the main takeaway is this: the domain model does not concern itself with data access, or frameworks, or infrastructure. So make sure to keep it plain and use abstractions to keep it unconcerned.

Section 7: Modeling the dimension of time

The event sourced domain model is a further evolution of the domain model which incorporates the dimension of time. By leveraging domain events as the source of truth for system data, it allows for a model that can provide deeper insight into the data, rich audit logging, and visibility into the state of the aggregates and entities at any previous point in their lifecycle.

Data storage and retrieval

The main characteristic that differentiates event sourcing from a traditional domain modeling is how the data that represents the aggregates is persisted. Instead of persisting the aggregate’s current state, event sourced domain models persist the domain events produced by the aggregates. These domain events are generated as a result of any operation that changes the state of the aggregate. Then, to obtain the current state of the aggregates, all the events are retrieved from storage and used to reconstruct the full object in memory.

In an event sourced domain model, aggregates produce events and commit them to the event store. To instantiate aggregates then, the same events are fetched from the event store and used to rehydrate the in-memory objects.

For example, in a database that backs an order processing system, an orders table might look like this:

id	status	email	phone	shipping_weight	country_code	created_at	updated_at
1	pending	john.doe@example.com	555-0101	2.5	US	2025-01-10	2025-01-10
2	paid	sarah.smith@example.com	555-0102	5.3	CA	2025-01-09	2025-01-11
3	shipped	mike.johnson@example.com	555-0103	1.8	GB	2025-01-08	2025-01-12
4	pending	emma.wilson@example.com	555-0104	3.2	AU	2025-01-11	2025-01-11
5	cancelled	david.brown@example.com	555-0105	4.7	US	2025-01-07	2025-01-13

Here, each row represents an order and their current state. The database schema resembles the order domain entity.

With event sourcing, what we persist into our database is a series of events that capture the full history of each order, as they journey through the system:

{
    "order_id": 123,
    "event_id": 0,
    "event_type": "order_created",
    "timestamp": "2025-01-10T10:00:00Z",
    "data": {
        "email": "john.doe@example.com",
        "phone": "555-0101",
        "country_code": "US",
        "status": "pending",
        // ...
    }
},
{
    "order_id": 123,
    "event_id": 1,
    "event_type": "payment_failed",
    "timestamp": "2025-01-11T12:00:00Z",
    "data": {
        "status": "payment_failed",
        "reason": "insufficient_funds"
    }
},
{
    "order_id": 123,
    "event_id": 2,
    "event_type": "payment_details_updated",
    "timestamp": "2025-01-11T12:05:00Z",
    "data": {
        "status": "pending",
        "payment_method_nonce": "new-nonce-xyz",
    }
},
{
    "order_id": 123,
    "event_id": 3,
    "event_type": "payment_succeeded",
    "timestamp": "2025-01-11T12:05:00Z",
    "data": {
        "status": "paid"
    }
},
{
    "order_id": 123,
    "event_id": 4,
    "event_type": "inventory_stock_updated",
    "timestamp": "2025-01-11T15:00:00Z",
    "data": {
        "status": "processing",
        "items": [
            {"product_id": "A1", "quantity": 2},
            {"product_id": "B2", "quantity": 1}
        ]
    }
},
{
    "order_id": 123,
    "event_id": 5,
    "event_type": "shipping_scheduled",
    "timestamp": "2025-01-12T09:00:00Z",
    "data": {
        "status": "awaiting_shipment",
        "shipping_number": "TRACK1234567890"
    }
},
{
    "order_id": 123,
    "event_id": 6,
    "event_type": "order_shipped",
    "timestamp": "2025-01-13T14:00:00Z",
    "data": {
        "status": "shipped"
    }
}

We call this database, the event store. This is an append-only storage mechanism that needs to support two features: fetching events that belong to a particular business entity and adding new ones.

// An event store only needs to support two features: fetching and appending.
interface IEventStore
{
    IEnumerable<DomainEvent> Fetch(Guid Id);
    void Append(Guid Id, IEnumerable<DomainEvent> events, int expectedVersion);
}

In code, when we want to retrieve an order from storage, what we do is fetch all its events, iterate over them and apply the changes they represent to an in-memory object, until it is fully reconstructed, or “rehydrated”. In the context of event sourcing, we call these representations of collections of events, projections. In an event sourced domain model, aggregates leverage these projections to figure out their current state.

// This is a hypothetical order aggregate in an event sourced domain model.
// Its constructor expects a collection of domain events which it iterates over
// to apply them to its internal state representaton object.
class Order
{
    private List<DomainEvent> _events = new();
    private OrderStateProjection _state = new();

    public Order(IEnumerable<DomainEvent> events)
    {
        _state = new OrderStateProjection();
        foreach (var e in events)
        {
            _events.Add(e);
            _state.Apply((dynamic)e);
        }
    }

    // Properties can be exposed to the outside world by leveraging the state
    // projection.
    public OrderId Id => _state.Id;
    public int Version => _state.Version;

    // ...
}

// This is a general use event sourced projection of an order, used to capture
// the current state of an order entity or aggregate.
class OrderStateProjection
{
    // This projection is meant to expose the full state of the order aggregate
    // so it includes all the properties that belong to the order.
    public OrderId Id { get; private set; }

    // With event sourcing, we need to keep track of the version of the entity.
    // Every event that happens increments the version number.
    public int Version { get; private set; }

    public OrderStatus Status { get; private set; }
    public PersonName Name { get; private set; }
    public EmailAddress Email { get; private set; }
    public PhoneNumber Phone { get; private set; }
    public Weight ShippingWeight { get; private set; }
    public CountryCode Country { get; private set; }

    public string PaymentMethodNonce { get; private set; }
    public bool InventoryResolved { get; private set; }
    public string TrackingNumber { get; private set; }

    // It defines a series of "Apply" method overloads, one for each supported
    // domain event. The Order aggregate from above passes all the domain events
    // to the various overloads, calling them one by one, in order, until the
    // full state is rehydrated into the projection. Each "Apply" overload takes
    // the data captured in its event and assigns it to the correct property in
    // the projection.
    public void Apply(OrderCreatedEvent e)
    {
        Id = e.Id;
        Status = e.Status;
        Name = e.Name;
        Email = e.Email;
        Phone = e.Phone;
        ShippingWeight = e.ShippingWeight;
        Country = e.Country;
        Version = 1;
    }

    public void Apply(PaymentFailedEvent e)
    {
        Status = OrderStatus.PaymentFailed;
        Version++;
    }

    public void Apply(PaymentDetailsUpdatedEvent e)
    {
        Status = OrderStatus.Pending;
        PaymentMethodNonce = e.PaymentMethodNonce;
        Version++;
    }

    public void Apply(PaymentSucceededEvent e)
    {
        Status = OrderStatus.Processing;
        Version++;
    }

    public void Apply(InventoryStockUpdatedEvent e)
    {
        Status = OrderStatus.Processing;
        InventoryResolved = true;
        Version++;
    }

    public void Apply(ShippingScheduledEvent e)
    {
        Status = OrderStatus.AwaitingShipment;
        TrackingNumber = e.TrackingNumber;
        Version++;
    }

    public void Apply(OrderShippedEvent e)
    {
        Status = OrderStatus.Shipped;
        Version++;
    }
}

Notice the Version field in the projection, which indicates the number of changes that the entity has gone through.

On the other hand, when it comes to appending new events for an aggregate, the event store needs to be aware of potential concurrency problems and handle them. After all, the ordering of the events matter. That’s why the event store usually implements optimistic concurrency control, leveraging the version field we touched on earlier. Essentially, when trying to append new events, the version being worked with is specified. If it doesn’t match the current version of the aggregate in the event store (maybe because some other process appended a new event), then the operation has to fail, or otherwise adapt to make sure the data remains consistent.

Advantages and disadvantages

One advantage of this design is that we can produce many distinct projections of the same underlying event sourced data. In the previous example, we saw a projection that represents the full current state of the order. But we might need other projections which are optimized for different use cases.

For example here’s a projection that captures all the statuses that an order went through, which might help different business analysis use cases:

// This projection only cares about the changes in status of the order, so
// instead of attempting to capture its full state, in keeps track of all the
// statuses in a collection.
class OrderStatusHistoryProjection
{
    public OrderId Id { get; private set; }
    public int Version { get; private set; }

    public List<OrderStatus> Statuses = new();

    // All the "Apply" overloads capture the status change that each event
    // caused.
    public void Apply(OrderCreatedEvent e)
    {
        Statuses.Add(OrderStatus.Pending);
        Version = 1;
    }

    public void Apply(PaymentFailedEvent e)
    {
        Statuses.Add(OrderStatus.PaymentFailed);
        Version++;
    }

    public void Apply(PaymentDetailsUpdatedEvent e)
    {
        Statuses.Add(OrderStatus.Pending);
        Version++;
    }

    public void Apply(PaymentSucceededEvent e)
    {
        Statuses.Add(OrderStatus.Processing);
        Version++;
    }

    public void Apply(InventoryStockUpdatedEvent e)
    {
        Statuses.Add(OrderStatus.Processing);
        Version++;
    }

    public void Apply(ShippingScheduledEvent e)
    {
        Statuses.Add(OrderStatus.AwaitingShipment);
        Version++;
    }

    public void Apply(OrderShippedEvent e)
    {
        Statuses.Add(OrderStatus.Shipped);
        Version++;
    }
}

We can even store these projections into separate databases if we need to. We’ll learn more about that aspect later when we discuss CQRS.

Another feature that we can implement easily thanks to event sourcing is time travel. We can easily apply the stored events up to a specific point in time or up to a specific version number and obtain the state of the entity as it was at that time. This can, for example, help troubleshooting, and unlock more avenues for business analysis.

An obvious disadvantage of event sourcing is the complexity that it introduces. This complexity, compounded by the potential learning curve on teams that aren’t used to this kind of design, can be very detrimental when utilized in projects that don’t need it. As usual, follow DDD’s core principle of tying the system’s design to the domain’s needs, make sure to use the right tool for the job, and only deploy an event sourced domain model when the situation really calls for it. That is, whenever requirements dictate that the features enabled by such a design are necessary.

The event sourced domain model

So, in summary, an event sourced domain model is a domain model that uses the event sourcing pattern to represent and operate on its aggregates. In a traditional, non-event-sourced domain model, the current state of the aggregates is persisted, commands modify this state and domain events are emitted for certain important operations, when needed. In the event sourced variant, domain events are used much more frequently, as they are the only source of truth. Everything and anything that changes the state of the aggregates produces an event. No changes are done directly, only through events. This is necessary because it is the events that are persisted, and it is from these events that the aggregates’ current state is derived.

In general, operations involving event sourced aggregates go through the following steps:

Load the aggregate’s domain events from the event store.
Reconstruct the aggregate’s state using these events. You can use the particular projection needed for the task at hand.
Run the necessary aggregate commands. Which in turn produce new domain events.
Append the new events into the event store. Making sure to handle any concurrency errors.

public class RescheduleOrderForPayment
{
    private IOrderRepository _orderRepository;

    // ...

    // This is the general pattern that application services often follow when
    // interacted with event sourced domain model aggregates: load events,
    // construct the aggregate with the events, run commands and save the newly
    // created events.
    public Result Run(OrderId orderId, string paymentMethodNonce)
    {
        try
        {
            var events = _orderRepository.LoadEvents(orderId);
            var order = new Order(events);
            var originalVersion = order.Version;

            // See below for what commands like these generally look like.
            order.UpdatePaymentDetails(paymentMethodNonce);
            order.ScheduleForPaymentProcessing();

            _orderRepository.Save(order, expectedVersion: originalVersion);

            return Result.Success();
        }
        // The repository uses the given version parameter to implement
        // optimistic concurrency control.
        catch (ConcurrencyException ex)
        {
            return Result.Error(ex.Message);
        }
    }
}

// ...

class Order
{
    // ...

    // Commands of event sourced aggregates don't modify state directly.
    // Instead, they create the appropriate events and append them.
    public void UpdatePaymentDetails(string paymentMethodNonce)
    {
        var e = new PaymentDetailsUpdatedEvent(_state.Id, paymentMethodNonce);

        _events.Add(e);
        _state.Apply(e);
    }
}

DDD tools for implementing business logic

These are the main concepts that we’ve explored, and how they relate to each other.

High Level System Analysis and Design with Domain-Driven Design

2026-04-06T00:00:00+00:00

Photo by Zed Jensen, 2022.

This is part 1 of a series of blog posts on Domain-Driven Design:

High level system analysis and design with Domain-Driven Design

Implementing business logic with Domain-Driven Design

Designing software architecture with Domain-Driven Design

Applying Domain-Driven Design in Practice

As a result, DDD offers a treasure trove of concepts, patterns and tools that can be applied to any software project, regardless of the size and complexity.

High level system analysis and design with Domain-Driven Design

Section 1. Analyzing business domains

It is a well understood notion that before writing code, we need to understand the problem we’re trying to solve. DDD is consistent with this notion and argues that developers need to, first and foremost, gain an understanding of the business that the software is being built for. To this end, DDD relies on three concepts: domains, subdomains and domain experts.

Domains and subdomains

In simple terms, the domain of a business is what it does, its area of activity. For example, Starbucks is in the business of making coffee, Ford is in the business of making automobiles, AMC is in the business of movie theaters.

Of course, analyzing a business as a single integrated whole can be unmanageable. That’s where subdomains come in. Subdomains are the different divisions within a domain. Starbuck’s domain for example, is making coffee. But there are many smaller parts that make up that business and allow it to be successful. There’s of course, the subdomain of coffee preparation. But there’s also real estate management to find and secure good locations, there’s inventory management and logistics, there’s marketing, there’s human resources, etc. All these are the subdomains that make up the overall business of Starbucks.

Depending on the business and on the project, these will vary greatly in granularity. And you can also decompose subdomains further and discover new fine-grained subdomains nested within more coarse-grained ones. The sizes and nesting levels can be very different from business to business, so it can be difficult to clearly delineate where a subdomain ends and another one starts, which activities belong to one or the other. One good rule of thumb to keep in mind is that generally, subdomains encapsulate a set of coherent, closely related use cases. That is, use cases that involve the same set of closely related actors, business entities and/or data.

And finally, we have domain experts. As the name suggests, these are the people within the organization who have intimate knowledge of the business, or certain areas of it. They are the subject matter experts. Usually they are the ones who identify the problems and come up with requirements. Developers need to rely on domain experts to gain the necessary understanding to be able to produce useful software solutions.

So, when approaching software projects, DDD suggests that developers work closely with domain experts in order to learn from them about the business domain and subdomains. After all, it is their mental models and understanding that will be modeled and implemented in code.

Types of subdomains

With the help of domain experts, developers can identify subdomains, understand their business value and how they fit within the overall business strategy. This is very important because it helps making some initial architecturally significant decisions. Namely, the general approach to solving the problems in the subdomains, how much to invest, how to organize development teams, etc. The main objective in this analysis stage is to identify the subdomains and whether they fall into one of three types: core, generic, and supporting.

Core subdomains are the activities of the business with highest value. The ones that confer differentiation in the market and a competitive advantage. They are the business’ raison d’être. For example, for Google, their search engine is a core subdomain. For Ford, their automotive engineering area would be a core subdomain. Core subdomains are generally the most complex parts of the business. They are constantly evolving and improving, and the company is compelled to invest heavily in them.

Generic subdomains are also very complex. However, they are not business differentiators. Instead, these are the areas of the business that all organizations handle in the same way. Think accounting, a ticketing system, an online storefront. There’s no pressure to innovate in these areas, so the solutions are very stable and evolution is slow.

Supporting subdomains on the other hand, do not provide any competitive advantage, nor are they very complex. They are however, necessary because they support the core business activities, and are fairly unique. The solutions to problems in these areas usually take the form of CRUD or ETL oriented activities. Imagine for example populating a data warehouse, translating transactional business data into a format appropriate for analytics and business intelligence in a manufacturing corporation. Or maybe the digitization and storage of a registry of court documents for a law firm. These are behind the scenes activities that support the organizations’ main businesses, but their business logic complexity is not high, and they don’t really represent big selling points for the company.

It’s worth noting as well, that there may be subdomains where software solutions are not appropriate, even if they are highly complex core subdomains. They are still part of the business so it’s worth identifying and considering for high level architectural design decisions. If anything, to know what parts of the business the planned software system should and should not focus on. You could have a restaurant, for example, who prides itself in having the best desserts in the city. For their business, the recipe development activities constitute a core subdomain. This is dependent on the art and craftsmanship of the chefs. Not an area in which software solutions could help a whole lot.

It’s also worth noting that, just as organizations’ business strategies are dynamic, so too can be their subdomain distribution. Today’s generic subdomain can be tomorrow’s core subdomain, and so on. For example, imagine a big retail store chain that, up until now, managed its inventory in an industry standard way. But it has grown so much that the standard way of doing things has become a bottleneck for them. So they design a new procedure for highly efficient inventory management, and that gives them an edge against competitors. Inventory management started as a generic subdomain for them, but due to an ever evolving business strategy, it became a core subdomain.

The knowledge of subdomain types can also help the analysis when dividing the business and discovering subdomains. If you find yourself recursively finding more and more fine-grained subdomains from already identified ones, a good time to stop recursing is when you find that a generic or supporting subdomain, when broken down, reveals only new finer-grained generic or supporting subdomains. The reasoning for this is simple: this analysis activity is most valuable when trying to identify core subdomains. When there are no more core subdomains to be found within a particular area of the business, then it’s probably not worth it to keep digging deeper.

Here we have an example of a hypothetical help desk system subdomain, part of a customer service subdomain, being decomposed and revealing that it only contains generic subdomains.

In summary, these are the main characteristics of the three types of subdomains:

Core subdomains have high complexity, provide competitive advantage, and change and evolve frequently.
Generic subdomains have high complexity, do not provide competitive advantage and change overtime, although at a slower pace than core subdomains.
Support subdomains have low complexity, do not provide competitive advantage and are the slowest to change.

This is where each type of subdomain fall when considering their business logic complexity and business differentiation.

Using subdomains to make strategic decisions

Like I’ve already alluded to, armed with this knowledge, DDD practitioners are ready to start making some higher level architectural decisions. Depending on the type of subdomain that a problem belongs to, DDD has specific prescriptions on how to handle the implementation of software solutions for them.

When working on core subdomains, that’s where we want to make the biggest investments. We deploy the most advanced engineering tools, patterns and practices. This is to make sure that the software is efficient and high quality, and also easy to maintain and evolve. This is necessary because core subdomains have to evolve rapidly by nature, if the business is to maintain competitive advantage. Software solutions that operate within the context of core subdomains have to be implemented by high skill and high trust teams. Either in-house, or via trusted development partners, working hand in hand with domain experts.

Problems in generic subdomains, by nature of their business logic being very complex but also very common, are likely to have already been solved. For these types of problems, DDD recommends against implementing custom software, and instead buying and/or adopting tried and true, industry standard, off-the-shelf solutions. Their implementation and integration can be outsourced or handled by less specialized or skilled teams. The change management of these solutions is simple, as they get delivered generally via patches and updates.

For support subdomains, whose business logic is generally simple but uncommon, it is less likely that off-the-shelf solutions would be available. So software addressing problems in these subdomains will most likely have to be implemented as custom solutions. Due to their low complexity though, they can be easily outsourced, or handled by more junior team members. They can also be handled with RAD, low-to-no-code technologies, since often times they are little more than ETL and pure CRUD applications.

Here’s a table to summarizes the differences between the types of subdomains:

Type of subdomain	Core	Generic	Supporting
Competitive advantage	Yes	No	No
Complexity	High	High	Low
Rate of change	High	Medium	Low
Implementation	Custom development	Buy/adopt off-the-shelf	Custom development
Team composition	In-house/partners	Can outsource	Can outsource
Skill level	High	High/regular	Low
Investment	High	Medium	Low
Problems	Interesting	Solved	Simple

Section 2. Discovering domain knowledge

After identifying the business domain and categorizing the various subdomains that compose it, we have a bird’s-eye view of the business. This is good enough to get started and make high level architectural decisions of potential software solutions to problems within these domains. To actually build the software though, we need much more than that. In order to gain a thorough understanding of the business logic, and be able to eventually model and implement it in code, DDD proposes the ubiquitous language as a tool.

The ubiquitous language

The ubiquitous language is DDD’s tool for knowledge sharing, effective communication and software modeling. In simple terms, the ubiquitous language is the language of the business. It’s the language that domain experts use on a day to day basis to talk and reason about the business.

For a software project to be successful, it’s essential that engineers and stakeholders understand each other. They have to be aligned when it comes to the meanings of the core concepts of the business domain. That’s why it’s so important that everybody uses the ubiquitous language for all project related communications, requirements, documentation, face to face discussions, and even code itself. It all needs to share the same language.

Engineers will need to interact with domain experts in order to learn about the business domain and its rules. They need to acquire the necessary knowledge that allows them to implement these rules in the software. During these interactions, they converse using the ubiquitous language. However, the knowledge transfer is not always strictly unidirectional. Yes, engineers have to learn from the domain experts. But also, through conversations and questioning, engineers can help domain experts deepen and flesh out their own understanding about their domains.

A classic example of this is when domain experts focus too much on the “happy paths” of given business processes. Then, through discussions with developers, on account of the inherent precision that software demands, they are forced to consider more edge cases, better specify ambiguous terms and fill out gaps in their understanding.

This deepening of knowledge feeds back into the ubiquitous language and improves it. Making it more insightful and more precise. This means that, throughout the life cycle of a project, the ubiquitous language should keep evolving, expanding and refining. This allows it to continuously improve as an effective model of the business domain, for the problem that it’s trying to solve. Indeed, just like code is a model of the business domain, so too is the ubiquitous language.

A classic pitfall in software projects is a manner of communication and knowledge sharing where developers are various steps removed from the domain experts. Consistent use of the ubiquitous language addresses this.

The ubiquitous language as a model of the domain

Through consistent use of the ubiquitous language, developers are able to obtain a deeper understanding of the domain, the problems we’re trying to solve, the reasoning behind the requirements and the mental model of the domain experts. This allows the construction of effective software solutions, with deep business insight, that go beyond simply translating requirements into code. If the implementation models the business domain effectively, there is potential for it to evolve with the business and better adapt as requirements change; and we reduce the risk of missing edge cases that may not be obvious to domain experts.

Under DDD, developers and domain experts develop the ubiquitous language, which then informs the implementation.

Effectively, when we build a ubiquitous language, we’re building a model of the domain. A model that reflects the relevant business entities, their behavior, and relationships. A model that will be eventually implemented into code, but also a model that needs to be understood by all stakeholders, regardless of their technical level. So it needs to be precise and rigorous, but also understandable. As such, in order to be useful, the ubiquitous language needs to respect certain restrictions:

It must not include technical jargon like programming languages, constructs or frameworks; nor mention specific system structures like database tables, servers or programs. It is the language of the business and it needs to be understandable by non technical folks.
It must avoid using the same term for different concepts. In conversation with humans, a lot of the meaning is extracted from the context. In software, not so much. Just like you can’t have two classes with the same name within the same namespace, the ubiquitous language cannot allow such ambiguities.
It should also avoid using different words for the same concept. The classic example for this is words like users, accounts, customers, visitors. They all refer to closely related concepts which might actually have differences. The problem with these overlapping terms is that those differences are obscured by the notion of them “being the same” and being used interchangeably. For usage within the ubiquitous language, it’s best to be precise and clearly delineate terms and definitions. Eliminate what’s redundant, be strict with definitions.
It should avoid including extraneous details. Just like code needs to include only what’s needed to solve the problem at hand and nothing else (in order to avoid accidental complexity); the ubiquitous language must not be polluted with details from outside of the area of business activity that it represents. That can create confusion and unnecessary cognitive load.

The ubiquitous language represents a unified model of the domain. This is in contrast to a more traditional process where domain knowledge gets “translated” multiple times before turning into code.

Tools for capturing the ubiquitous language

The Agile Manifesto declares: “Individuals and interactions over processes and tools”. And of course, when it comes to the ubiquitous language, direct interaction and conversations between engineers, domain experts and other stakeholders reigns supreme. That’s when it can be most useful. It can also be useful, however, to capture the ubiquitous language in documentation and even in runnable form.

A glossary of terms is a great asset for keeping a ubiquitous language. A wiki is a good place to put this. Definitions for key concepts in the business like entities, processes and rules can be captured here. The only caveat is that documentation is static by nature, while the ubiquitous language is continually evolving. So, great care needs to be taken to keep the wiki updated at all times to reflect the latest and most complete understanding of the domain. This should not be relegated to or gate-keeped by only certain people; it should be a team effort where everyone contributes.

An automated acceptance tests suite, written using Behavior Driven Development frameworks, like Cucumber, is also a great way of capturing the ubiquitous language. The advantage of these tests is that they are written in plain human-readable language, not code. And while it may be far fetched to think that non technical domain experts would be capable of writing and maintaining such tests, they certainly can read and understand them, which is a great boon. These tests speak the language they understand: the language of the business.

This is what Cucumber tests look like.

By nature of being executable and tied closely to the implementation code, there is less chance that they become out of date. This can happen more easily with static documentation written in a wiki. The disadvantage is that they require much more effort. But for the right kind of project, one where business logic is very complex or the scope is very wide, they can be very well worth the cost.

Section 3. Managing domain complexity

We can attempt to model an entire business domain with one big ubiquitous language, but sometimes that’s impossible. Especially so for businesses of a certain size, you will inevitably find inconsistencies and conflicts between the mental models of different domain experts. The simplest example of this scenario is when different experts from different areas of the organization have the same word to describe different concepts. Or when they look at the same business entity with different levels of detail.

When the different mental models are valid, and these inconsistencies are legitimate and cannot be reconciled, the solution is to follow the divide and conquer principle and decompose the language into separate ones, each one working within its own bounded context.

Simply put, a bounded context is the context within which a ubiquitous language, and the model it represents, operate, have meaning and are useful. Sure enough, just like a domain can be divided into subdomains, a ubiquitous language can be decomposed into smaller languages, each with its own context, to model different parts of the business. While we can attempt to capture an entire business domain with a single model, this is not advisable in the case of complex systems. It’s better to split up the model into smaller, more precise ones, tailored to work on specific problem domains.

Reasons for creating bounded contexts

Like mentioned before, different domain experts having conflicting mental models is a clear indication that a division in the model needs to happen. However, that only tells us half of the story. There are other indicators that point to when and where further division should happen:

First of all, there is of course, size. Size by itself is not a deciding factor, but it is something to consider and balance. Fewer, bigger models can help keep the overall environment simpler, but if they become too big they can become unmanageable and prone to corruption. A higher number of smaller models keep cognitive load low, but you run the risk of exploding integration and management complexity. The better principles to keep in mind here are coupling and cohesion. Beware of separating closely tied use cases, that deal with similar actors, entities and data.

System-level nonfunctional requirements also play a role in dividing a model into separate bounded contexts. For example, you might need to decouple the life cycle of several software components. Have them be developed, evolved, versioned and deployed independently. You might also need them to scale separately. You might even need to use completely different technology stacks, whatever is appropriate for the task at hand. This means that bounded contexts generally get implemented as individual services and/or applications. That is, as individual runtime components.

The organization’s composition also plays a role when designing bounded contexts. The general rule is that a given ubiquitous language, the model it represents and the bounded context is lives in, must be owned by a single team. In software, high ownership, cohesion and consistency are desirable traits. Having a single team own and maintain a particular component foments these. Single ownership also helps reduce communication overhead, and prevents people from stepping on one another’s toes. Of course, a single team can own multiple bounded contexts, what cannot happen is one bounded context being owned by multiple teams.

Indeed, in bounded contexts, we have the tools we need to make strategic decisions related to the decomposition of software systems into architecturally significant components or modules. With bounded contexts, we are able to specify the physical and ownership boundaries of these components.

Bounded contexts vs subdomains

Bounded contexts and subdomains are closely related concepts, but there’s one key distinction: subdomains are discovered, while bounded contexts are designed. Subdomains are useful because they help us understand the business strategy. Splitting the business domain into smaller problem domains is useful because it can break down a complex whole into smaller and more manageable parts.

Depending on the situation, it is certainly possible to end up with a set of bounded contexts that align one-to-one with the business subdomains. However, this is not mandatory. We can develop a solution with a single bounded context that spans multiple subdomains; the same way that we can decompose the problem into many bounded contexts, some of which operate within the same particular subdomain.

Bounded contexts are closely related to subdomains, but aren’t tied to them. They are flexible and can be organized in many ways.

Each bounded context becomes a separate major architectural component. That is, a (micro) service, a project, an application. When we have a component that spans multiple subdomains, programming language organizational structures like namespaces or modules can be used to logically separate the subdomains within.

Section 4. Integrating bounded contexts

For a system to function, its components need to interact with each other. So, once we have decomposed the problem domain into separate bounded contexts, we need to decide their relationship and integration strategies. This need for interaction between them implies that there are touch points between bounded contexts. We call them contracts.

These contracts are necessary because each bounded context contains its own version of the world. That is, its own model and ubiquitous language. In order to integrate, some level of translation needs to happen. They need to be adapted to one another. The contracts define these adaptations.

Domain-Driven Design offers various patterns that are useful for defining contracts between bounded contexts. The decision to use one pattern vs the other depends greatly on the nature of the teams tackling the project. Depending on the teams’ relationship, we can put the patterns in one of three categories: cooperation, customer-supplier, and separate ways.

Integration patterns are determined mainly by the level of cooperation between the teams that own the interacting bounded contexts.

Cooperation patterns

When the components that need to interact are owned by teams which are in close communication, work well together, and whose goals are aligned, cooperation patterns can be applied.

If the teams meet these criteria, a partnership model can be implemented. This is where the integration is managed in an ad-hoc manner. Both teams work together to define the API through which their components interact and that’s that. Whenever changes happen on either side, the other team learns about it quickly and adjusts their code right away. Continuous integration is a great tool here, as breakages are immediately apparent, closing down the feedback loop.

Sometimes, when different bounded contexts need to implement the same functionality, it makes more sense to develop this functionality once and package it as a reusable library, or a sub-module within a shared repository. This is what DDD calls a shared kernel. A shared kernel is effectively a bounded context of its own, one that is statically linked to other components and implements the logic that others depend on.

A shared kernel is its own bounded context, but also “belongs” to multiple other bounded contexts.

The shared kernel integration pattern needs to be used carefully though, as it creates tight coupling between the components that use it. If the involved bounded contexts are owned by different teams, then this shared kernel that emerges violates the DDD principle of bounded contexts having single-team ownership. This is something to watch out for, as bad team synergy can produce problems during development and maintenance.

When using a shared kernel, the quality of the communication and the coordination between the teams has to strike the right balance: when they aren’t strong enough to support a partnership model, but not so weak that the shared kernel would become more trouble than it’s worth.

The alternative to a shared kernel is the duplication of the logic across multiple components. When deciding whether to apply this pattern, the costs of duplication vs coordination need to be considered. That is, the cost of implementing the same logic within multiple components and its subsequent changes, vs the cost of changes in the shared kernel propagating into dependent components and coordinating with the owners of each. When it is cheaper to just duplicate the logic, shared kernel should not be applied.

This means that complicated models that change frequently, like those of core subdomains, are good candidates for shared kernel. Shared kernels allow complexity to be encapsulated and exposed through stable contracts. This means that frequent changes are easier to contain. Frequent changes in logic that’s highly complex and also repeated in multiple places, quickly becomes much more expensive to maintain.

Another good scenario for applying a shared kernel is when refactoring a legacy monolithic system into more separated modules. The legacy system can become the shared kernel during the time that modules are being extracted from it but not yet fully decoupled.

Customer-supplier patterns

Customer-supplier patterns establish a relationship between components where one (the provider, who is “upstream”), provides a service to another (the consumer, who is “downstream”). These types of patterns emerge when the teams who own the involved bounded contexts are not in close collaboration and have their own independent goals.

One form of customer-supplier integration is the conformist pattern. This happens when the supplier defines the integration contract/API, using its own language, concepts and model, and the consumer accepts it. This can happen when the upstream service has a well established or industry-standard model. Or maybe the model is “good enough” for the consumer to interact with directly. Organizational politics may also be a reason for this type of integration, where there is an imbalance of power favoring the supplier’s team, and they get to impose their model or can’t be bothered to adapt it.

Sometimes, the consumer won’t accept the supplier’s model. In that case, an anticorruption layer can be created. An anticorruption layer is implemented by the consumer and translates the supplier’s model into its own. This allows the consumer to use the supplier’s service without polluting its model with extraneous concepts.

Anticorruption layers can be good solutions for the following scenarios:

When the consumer represents a core subdomain. The consumer is solving hard and interesting problems, so it’s best to protect its model with the ACL.
When the supplier’s model is messy and inconvenient. The ACL can protect the consumer’s model from having to contend with a mess of extraneous concepts.
When the supplier’s contract changes frequently. The ACL can protect the consumer from those changes, encapsulating them, allowing it to be less volatile.

A third pattern represents an anticorruption layer of sorts, only built on the supplier’s side. DDD calls this the open-host service pattern. Here, the upstream service comes up with a new language, separate from its own, tailored to its consumers’ convenience, and exposes that as its contract. This public protocol is called a “published language”.

An open-host service provides a protocol for consumers to interact with. It can also support multiple versions of this protocol simultaneously.

An open-host service applies to similar scenarios as an anticorruption layer. Decoupling a service’s internal model from its integration model frees it up for continuous evolution without fear of breaking its consumers. Another advantage of this is that multiple versions of the published language can be exposed, affording clients options on what to support and gradually migrate if they so choose.

Separate ways

Sometimes, the right decision is to not integrate at all. I alluded to this outcome back when discussing the pitfalls of the shared kernel. Sometimes duplication, in spite of how bad it smells, may be the most cost effective solution to a given situation. So the teams go their separate ways.

This can happen when the involved teams cannot collaborate effectively for whatever reason. It could be due to geographical, timezone, or organizational issues.

This can also be a good solution when the repeated logic belongs in a generic subdomain, and it’s easy to integrate. For example consider a logging framework. Exposing that kind of functionality in a service for others to consume, in most cases would be much more trouble than just including some third party library or package.

It may also be that the models being integrated are just so different that they are fundamentally incompatible. It may be cost-prohibitive for collaboration or customer-supplier patterns to be applied; and duplication again, is cheaper.

Going separate ways can be dangerous when we’re talking about core subdomains though. So we have to tread carefully in those scenarios. Remember that models that represent core subdomain should be implemented in the most effective and efficient ways, with few shortcuts and minimized technical debt.

The context map

The context map can be a useful tool for high level design as it plots all the major bounded contexts (i.e. modules, components, subsystems) that we’ve designed and their interaction patterns.

Here’s a context map which captures the various bounded contexts that compose a big system and their interactions. The arrows point to the upstream component in the relationship. “ACL” denotes an anticorruption layer and “OHS” represents an open-host service.

Of course, they can also offer valuable insight into organizational dynamics, as team composition and relationships with others are intrinsic parts of the discussion when talking about bounded contexts. For example, it can show teams that prefer to collaborate closely or at a healthy distance. I can also show problematic components, which are surrounded by anticorruption layers or have had their ties completely cut via a separate ways approach.

As with any document, they run the risk of becoming stale as the system evolves. So it should be a team-wide responsibility to keep it up to date. Each team taking care of their own components and their integration points.

The DDD high level design concept map

These are the main concepts that we’ve explored so far, and how they relate to each other.

Choosing Between SaaS and a Custom Website

2021-05-18T00:00:00+00:00

Photo by Daniel McCullough

So you need a website, but you’re not sure whether you want to pay for a website provided as software as a service (SaaS), or build a custom website and host it.

The options are plentiful, as are the reasons for building a website in the first place. The purpose of this article is not to put forward specific packages or providers for consideration, rather I want to discuss how you might make that decision more objectively. Also, this discussion is for a commercial website, not a personal website or blog.

Here at End Point, we receive many inquiries asking for new websites. We are well equipped to help you work through this process, and are happy to do so. But for those of you who want to “go it alone”, or if you just want to be better prepared before giving us a call, read on for some things to consider as you make a pros & cons list for SaaS vs. custom websites.

While deciding between a SaaS offering and a custom build carries unlimited considerations, here are a few main points to help you narrow down the field.

Experience

The foremost factor that you should consider for your pros & cons list is your experience. This may come as a little bit of a shock, as you might think that budget would be the top consideration. Budget is very important, but it is largely determined by your experience with your chosen technology. Don’t think for a minute that either SaaS or custom development cannot consume almost any budget, especially when you are working with an unfamiliar technology.

So before budget, comes experience. Experience can be futher divided into experience with your business and experience with websites in general. Here are a few questions to start off with.

In your industry, are you a:

Rookie
Veteran

How long have you owned this business?

1–3 years
3+ years

Does this business have an existing website?

If yes, is it currently SaaS or custom-developed?

SaaS
Custom-developed

If you answered “1” to more than half of the above questions, it’s more likely that a SaaS system would be a better fit for you. If you mostly answered “2”, you may want to lean towards custom. These questions are not definitive, but are meant to help you decide where to focus your research.

Budget

In general, if your budget is under $10,000 then SaaS is most likely the choice for you. Some exceptions here:

You are a talented web programmer.
Your brother, sister, friend, or cousin is a talented web programmer.
You or your developer friend have enough time to devote to this endeavor. You will need a lot.

Custom websites are no longer appropriate for the average business owner with less than a $10k minimum start up cost, as well as a $1–3k monthly budget for ongoing improvements and maintenance. Currently, droves of talented programmers are working for SaaS companies, building tools for you to use to build your own website. In fact, SaaS offerings are so much cheaper and more widely supported that building a custom site for the average small business usually makes little sense.

If your budget is $10k or more, you are probably capable of funding a custom website. However, this alone should not rule out a SaaS website. SaaS offerings come in many shapes and sizes, and many are fully capable of running enterprise-level websites!

How does your business make money?

One good case for using a custom website is if your company offers a niche product. Most SaaS offerings are based on popular business or product templates, so they might not fit well if you need to break from the mold.

For example, do you sell clothing, movies, or tools? There are great SaaS offerings out there that can have your website up and running in less than a day. Do you provide a service that uses multiple providers, working in different capacities and for different rates depending on the level of service provided? You may need a custom application! The further from commonplace your products or services are, the more likely it is that you will need a custom application.

Again, all of this advice is general, and there are exceptions to every rule. SaaS choices still require customizing to fit your business model. None of them will fit perfectly, and you will usually need to configure and add plugins to make your site conform to your business practices. SaaS offerings typically have a wide range of plugins and customizations to accommodate this. Those extras usually cost extra too.

While SaaS sites do provide a great starting point with a plethora of potential plugins, in many cases plugins are supplied by 3rd parties. That means that if you have problems with the plugin, you will need to deal with that provider separate from the main service provider.

A lot of time and money can be spent trying to make diverse systems work together. SaaS can be more “turn-key” in the beginning, but especially for more complex websites, it can end up costing more than if you created a custom site in the beginning.

What vendors does your company work with?

Vendors are sometimes overlooked when trying to decide on what type of website will be needed. Here are some questions which might complicate your website:

Do you use a 3rd party to ship or fulfill your products?
Do you sell your products on Amazon, Google Shopping, or other providers?
Do you use a vendor to provide your products to you?
Do you assemble the product after receiving parts from different vendors?
Does your company use any software for customer management, accounting, or shipping?

If your answer is yes to any of these questions, you need to know what platform each of those vendors or platforms use, and if it is compatible with the website you are planning to build. Almost all business done today involves the exchange of information between you, your customer, and your vendors.

That exchange of information usually takes place through an Application Programming Interface (API). If you aren’t familiar with APIs, here’s a great explanation. Understanding how websites communicate with your vendors is very important.

The point is that if you plan on doing any volume of business, at some point you will need to exchange information with some vendor or other. Verifying that your new website is capable of exchanging information with existing vendors is a big consideration for you to make before you build. Building a website without the required APIs would be like building a house without any provision for water, plumbing, or electricity. This is important stuff, and it can get very expensive to retrofit!

Is that all?

Absolutely not. There are endless considerations that can play into your decision. But hopefully this post has given you some good ideas of where to start and will help you avoid analysis paralysis. Use this information to get a good idea of your needs and document them, so that you can investigate the right things. Compare how well different solutions fit your needs.

Who knows, you may start with a SaaS solution for a few years, and then when things are rolling and you have a better handle on your site layout, migrate to a custom-built site. There are no set rules.

Don’t read an ad for a website service offering to find out you what you need in a website. Determine what you need in your website and look for a product which meets your needs!

Why upgrading software libraries is imperative

2020-06-10T00:00:00+00:00

Image by Tolu Olubode on Unsplash

Applications primarily run on front- and back-end programming languages, including library dependencies. Operating systems and programming languages can be periodically updated to run on the latest version, but what about the many libraries being used in the app’s front and backend? As we all know, it can be quite a daunting task to maintain and individually update a long list of software dependencies like the examples later in this post. Still, it is important to keep them updated.

This post dives into our experience upgrading a complex app with a full software stack and lots of dependencies. We’ll examine the benefits of upgrading, what you will need, and how to go about such an upgrade as simply as possible.

The app in question contained decade-old software and included extensive libraries when we received it from our client. The app used languages including Java, Scala, Kotlin, and JavaScript along with many libraries. The initial plan was to upgrade the complete software stack and libraries all at once due to the gap between versions. This proved to be more difficult than expected due to a host of deprecated and removed functionality as well as interdependence of a few of the libraries.

Conflict approach: “Don’t update unless you have to”

While this can be sustainable in the short term, it quickly becomes less applicable in the long run. One important purpose of updates is to (hopefully) protect from new vulnerabilities and cyber attacks. Scenarios arise where particular library fixes are implemented on the latest version, yet require upgrading other libraries to the latest version in a chain. Because upgraded libraries need extensive testing and preparation for new issues, this directly impacts whether the app attempts to resolve an issue.

Therefore, smaller and more frequent updates are more sustainable in the long run. Larger and less frequent upgrades will not only result in unexpected errors, but also require more complete regression testing to deliver a bug-free update. The following reasons justify the necessity of software and library upgrades:

They apply timely security patches to reduce vulnerabilities and defend from cyberattack
You can identify deprecated functionality earlier and use alternatives
They can apply fixes for known bugs in the library
They’re based on the latest versions of software or library, encouraging stability

In addition, staying on the latest major version yields the benefit of applying minor and patch releases seamlessly without risk. Most software and libraries use semantic versioning, formatted as MAJOR.MINOR.PATCH:

MAJOR version - Incompatible API changes
MINOR version - Add functionality with backward compatiblity
PATCH version - Bug fixes with backward compatibility

So being on the latest major versions of libraries allows applying minor and patch releases without breaking existing functionalities of the app.

Benefits

The benefits of keeping software and libraries updated include bug fixes, new features, boosted performance, as well as better stability, compatibility, and security measures. We can often ignore upgrades in projects because we don’t perceive significant effects in appearance or usage. But on closer inspection, frequent updates deliver important advantages.

Real-time difficulties

In real-life scenarios, bug fixes and performance optimization of an app often take a higher priority than upgrading libraries. In many cases, this results in a discrepancy between the app’s version and the current version. This discrepancy can lead to the following issues when upgrading libraries:

Unexpected error handling in new releases
Unexpected unsupported library dependencies
Need for complete end-to-end testing due to major version of library upgrade
Lack of work being visibly completed can lead to a lack of confidence from client
Difficulty in estimating workload due to major unexpected errors

The following passages offer guidance in how to adequately prepare for these issues.

Get prepared

Much can be learned from preparing for a major upgrade on both a business and technical level. First, a complete list of libraries from the entire app should be compiled. This list should include the latest and current version of the library in the app. Reviewing the changelog of both versions will help identify potential incompatibilities or problems. Visiting the “issue report page” of the library to monitor any version-specific issues is also recommended.

Once you’ve adequately prepared the libraries for upgrading, you can use any method of your choosing to upgrade and maintain the list. Once the roadmap is established, upgrading can commence and compatibility issues that arise can be dealt with as they arise. Finally, thorough end-to-end testing is necessary once the upgrade process is complete.

Below are some examples of software lists you might have for a project (we left out the latest versions for brevity in this post, but it’s helpful to have a column for those too!).

Programming software & servers

Software	Running	Release date
Ubuntu Linux	12.04.5	2017-04-28
nginx web server	1.12.2	2017-10-17
Jetty Java Servlet container	9.2.3	2014-09-05
JVM/Java	1.7u79	2015-04-14
Scala	2.11	2014-04-21
Kotlin	0.9.223	2014-10-23
Lucene	4.10.0	2014-09-03
PostgreSQL database	9.3.10	2015-10-08

Java libraries

Software	Running	Release date
joda-convert	1.3.1	2013-03-01
joda-time	2.2	2013-03-01
play-json	2.7.0	2019-01
httpclient	4.1.2	2011-07-10
httpcore	4.1.2	2011-07-22
httpmime	4.1.2	2011-07-29
commons-codec	1.3	2005-10-01
jooq	3.1.0	2013-06-30
jooq-codegen	3.1.0	2013-06-30
jooq-meta	3.1.0	2013-06-30
jtds	1.3.0	2012-10-27
servlet-api	3.1	2013-04-25
play-json-joda	2.11-2.6.9	2018-03-01
lucene-core	4.10.0	2014-09-02
lucene-memory	4.10.0	2014-09-02
lucene-queries	4.10.0	2014-09-02
lucene-queryparser	4.10.0	2014-09-02
lucene-highilghter	4.10.0	2014-09-02
lucene-analyzers-common	4.10.0	2014-09-02
postgresql	9.2-1003-jdbc4	2013-05-27
jsoup	1.7.3	2013-11-11
jetty-util	9.2.5.v20141112	2014-11-12
tika-core	1.16	2017-07-07
commons-fileupload	1.3	2013-03-24
commons-beanutils	1.6	2005-11-08
commons-collections	2.1	2005-11-08
commons-digester	2.1	2010-09-24
commons-io	1.1	2005-11-24
commons-lang	1.0.1	2005-11-24
commons-logging	1.0.3	2005-11-17
commons-validator	1.0.2	2005-11-24
slf4j-api	1.6.4	2011-10-31
slf4j-nop	1.6.4	2011-10-31

JavaScript libraries

Software	Running	Release date
angular	1.2.11	2014-02-03
jQuery	1.10.2	2013-07-03
calendar	1.51	2005-03-07
calendar-setup	1.25	2005-03-07
fckeditor	2.6.11	2014-06-02
dom-drag	—	2001-10-28
jt_DialogBox	29	2012-08
jt_AppDialogs	9	2005-05
ng-grid	2.0.7	2013-06-07
ng-grid-flexible-height	2.0.7	2013-06-07
ng-grid.css	2.0.7	2013-06-07

Recommendations

Once the app’s software stack and libraries are up to date it’s important to regularly update. The complete upgrade experience can be a rigorous and involved process that includes juggling numerous issues and intensive testing.

From a client’s perspective, a major upgrade project often doesn’t obviously demonstrate improvement to appearance or function. Because it is not recommended to keep outdated software and major upgrades (such as the one described above) are tedious, the following update options are preferable in order to keep software libraries as up-to-date as possible:

Interval Based: Particular interval periods are implemented to check versions of software. This minimizes frequency of problems while ensuring a manageable gap between the current and latest software version.
Module Based: Whenever work is performed on any module for new features or bug fixes, software and library versions are reviewed. This allows for relevant libraries to be updated, tested, and deployed along with development changes within the module.

Conclusion

Even if new features and improvements are not pertinent to the new release, frequent upgrades to software and libraries are crucial in order to ensure the most secure and debugged versions. Please feel free to share your methods of managing software updates in a comment!

In-House to Consulting, Rinse and Repeat

2018-03-28T00:00:00+00:00

Photo by Matthew Henry of Burst

Hi! I’m Steph. I’ve been working 10+ years now as a software engineer, and I’ve spent ~4 years of that as an in-house developer at 2 different companies and 7+ years as a consultant here at End Point and as an independent contractor. Whenever I’ve started a new position, I get asked “What’s it like on the other side?” or something along the lines of “Is the grass greener?” I thought my answer to this was good blog fodder, so here we are.

If you google “in-house vs. consultant”, much of the results are written from the perspective of a company looking to hire either in-house engineers or looking to outsource to consulting companies. Here’s my approach to answer the question as it relates to employee happiness, skill development, and job satisfaction.

Working as an in-house engineer

Working as an in-house engineer can mean that you may focus on one technology (or one web stack) and even one main codebase, although this isn’t necessarily true. When I worked for Backcountry.com a while back, the main application was an ecommerce application running on Interchange, and that’s where I spent most of my dev time. But as my experience grew, I began working on other internal B2B tools as well.
With a small team, it’s possible you might adopt consistent style rules in the code.
In an engineering role as an in-house dev, you might not be directly involved in sales efforts of the company.
With a small, single team, there is only one set of team dynamics that you have to navigate between, which might allow you to build stronger relationships with those team members and understand how to work with those team members efficiently. Of course the disadvantage of this is if you don’t get along with a team member, you should learn how to work with them.
Working as an engineer for a product company might mean a steady stream of income and less micromanaging of expenses. This might translate to benefits like maternity leave, simply because the revenue stream can support paid leave, but this isn’t necessarily true and highly dependent on the circumstances. On the flip side, if the company isn’t doing well financially, there isn’t a resource for additional income, which could translate to loss of jobs for employees.
From my experience, working with a small team, there have been better processes in place for code review and code feedback, ultimately resulting in better growth of individual engineers. I have found that while I was an in-house engineer, I did a deep dive into one technology stack, and my skills greatly improved with that depth of experience.

Working as a consultant

Working as a consultant often offers the ability to be exposed to many technologies, many technology stacks, and more variety.
From my experience, adaptability is highly valued in the consulting space because you are exposed to different technology stacks and development processes. It is valuable to move seamlessly between teams and technologies.
Depending on how your company is set up, there can be a wide range of types of client interaction. Some clients want to learn how to make website changes and your role is to support them in that desire. Other clients may be hands-off all dev work, expecting you to have the expertise to drive technology choices. Clients may have very limited budgets and want a consultant to provide the most value to them. Client management is very important here.
In consulting, from my experience, it is not unusual to participate in sales efforts to provide estimates or technical solutions for proposals.
While I find many successful software engineering consultants have a breadth of knowledge, companies can often grow talent in specific areas or with specific hires to gain a depth of knowledge in specific technologies. The benefit to other employees is the access to expertise that may translate to better efficiency for clients (for example when I ping other expert co-workers when a question is not in my skillset).
By nature, consulting is diverse, so job stability may be decent if clients are overall successful and you are successful in working with them.

Working for a company that does both consulting and product development

I’ve seen a few companies that have been successful in both consulting and product development, where their employees develop a product but supplement company income with expert consulting.
From an employee perspective, this may offer a nice balance between breadth and depth in working on specific technology stacks.
A company that does both product development and consulting successfully may be more stable financially due to diversified income streams.

In-house & consulting

In both scenarios, I’ve found there is always a feedback loop going on in during active software development. You complete some task, pass it on for review, wait for feedback from a decision maker to iterate to the next step or adjustments. I like to fill in time when I’m waiting by working on another feature (in-house) or other client work (consulting).
My personal experience has taught me that communication is one of the most valuable assets to have as a software engineer, because you are responsible for translating business needs to software. The better you can communicate with intent, the more efficient you will be as an in-house engineer and as a consultant.
The ability to calculate work effort and manage priorities is also a highly valued skill in both employment circumstances.
From my own experience, I’ve been lucky to receive flexibility in both scenarios working half/part-time since my first daughter was born. In the consulting space, working limited time may be suitable for limited client budgets, but as an in-house engineer working half-time translated to less output while still providing knowledge from previous experience.
I’ve also found that in both scenarios, some job satisfaction comes from the happiness of the client (or decision maker), which can put you in a difficult position if your client isn’t happy. Every time the decision maker walks away dissatisfied, I think you have an opportunity to improve how to communicate and work with them to build a successful relationship.

Conclusion: Is the grass greener on the other side?

If you ask me “What’s the best option for me?”, I can’t answer that for you in your particular circumstances. I think an in-house position establishes a good foundation in a single set of technologies that could be beneficial as you progress in your career should you choose to climb the ladder in your current position or move to a consulting position. But if you are adaptable, and want to grow your breadth of experience and exposure to technologies, I think consulting is a good fit.

In true consulting form, I can only suggest to anyone considering a job change from one to another that you evaluate factors such as job satisfaction, compensation, flexibility, and stability when you are evaluating your options.

Reconciling Android source code

2017-12-19T00:00:00+00:00

Recently, a client came to us with an interesting problem. They needed some changes made to an internal-use Android app that had been created for them by another company, but they didn’t have up-to-date source code for the app, and they had no way of getting it. They gave us an old archive of source code, a more recent working build of the app, and asked us to figure it out.

The working version of the app they sent us was built in early 2016, and the app was compiled for Android SDK version 22, which is 5.1 Lollipop. It came out in March 2015, so it was a year old even when the app was created, and the code was using lots of features which have since been deprecated.

After putting this source code in a Git repository, I started by building the app from the source they’d sent and comparing it to the working version. It looked mostly the same, but a couple of features were broken. At the suggestion of a coworker, I used BytecodeViewer to decompile the APK and took a look around.

It was a little while before I was able to find any differences between the source we had and this decompiled code, but I did find a few logic differences. The source was also using a few old APIs that needed to be updated. With the needed changes made to the source code, I soon had a working build of the app that matched the functionality of the built APK we had.

This wasn’t the only thing wrong with the app, however. Another hurdle in picking up this project from its previous developers showed up when I had to fix a few odd problems reported by the users. One problem was on an information screen listing attributes of items. An example:

The “Quantity” field worked just fine for any non-zero value, but if it was 0, the app was displaying 16 instead. This turned out to be very simple to fix. Below is the layout code involved:

<TextView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:textAppearance="?android:attr/textAppearanceMedium"
    android:text="16"
    android:textColor="@color/background_black"
    android:id="@+id/txt_info_quantity" />

The default text of that field was, likely as a placeholder, set to 16, and it wasn’t being overwritten when the given value was 0. So, all I had to do was replace it with 0, since it would be overwritten anytime there was a nonzero value.

This was a good reminder to somehow keep track of placeholders like this, for example, putting a todo comment or something similar, so bugs like this can be caught in code reviews.

Figuring out how to reconcile the source and binary of this app seemed like a daunting task, but it turned out to be very doable, and was a very interesting project.

Applying Domain-Driven Design in Practice

Table of contents

Section 10: Design heuristics

Bounded contexts

Business logic implementation patterns

Architectural patterns

Testing strategy

Section 11: Evolving design decisions

Changes in the domain

Organizational changes

Domain knowledge changes

Growth

Section 12: Domain-driven design in the real world

Strategic analysis

Modernization strategy

Selling Domain-driven design

Finally

Designing software architecture with Domain-Driven Design

Table of contents

Section 8: Architectural patterns

Layered architecture

Ports and adapters

Command query responsibility segregation

Scope

Section 9: Communication patterns

Model translation

Stateless model translation

Stateful model translation

Integrating aggregates

Outbox

Saga

Process manager

Architectural patterns to use within bounded contexts

Patterns for communicating across bounded contexts

Implementing business logic with Domain-Driven Design

Table of contents

Section 5: Implementing simple business logic

Transaction script

Active record

When to use them

Section 6: Tackling complex business logic

Domain model

Value object

Entities

Aggregates

Domain event

Domain service

Data access concerns

Section 7: Modeling the dimension of time

Data storage and retrieval

Advantages and disadvantages

The event sourced domain model

DDD tools for implementing business logic

High Level System Analysis and Design with Domain-Driven Design

Table of contents

Section 1. Analyzing business domains

Domains and subdomains

Types of subdomains

Using subdomains to make strategic decisions

Section 2. Discovering domain knowledge

The ubiquitous language

The ubiquitous language as a model of the domain

Tools for capturing the ubiquitous language

Section 3. Managing domain complexity

Reasons for creating bounded contexts

Bounded contexts vs subdomains

Section 4. Integrating bounded contexts

Cooperation patterns

Customer-supplier patterns

Separate ways

The context map

The DDD high level design concept map

Choosing Between SaaS and a Custom Website

Experience

Budget

How does your business make money?

What vendors does your company work with?

Is that all?

Why upgrading software libraries is imperative

Conflict approach: “Don’t update unless you have to”