Tag: DDD

Domain-Driven Design

This post is part of The Software Architecture Chronicles, a series of posts about Software Architecture. In them, I write about what I’ve learned on Software Architecture, how I think of it, and how I use that knowledge. The contents of this post might make more sense if you read the previous posts in this series.

Domain-Driven Design was coined by Eric Evans in his fantastic book Domain-Driven Design: Tackling Complexity in the Heart of Software, published in 2003. Eric Evans book was key in formalising many of the software development concepts that today we take for granted.

I can’t make an exhaustive review of DDD in a blog post. There are just too many important concepts associated with DDD. Fortunately, that’s also not the goal here. What I will do, however, is to list the DDD concepts that I find more relevant for the way I like to organise code and how I think of Architecture: the system-wide concepts that constitute the foundations for feature development.

In this post, I’m going to write about:

  • Ubiquitous language
  • Layers
  • Bounded contexts
  • Anti-Corruption Layer
  • Shared Kernel
  • Generic Subdomain

Continue reading “Domain-Driven Design” →

DDD Europe 2017: The 3 talks I most enjoyed

Last week I attended the DDD Europe conference. This was the 2nd edition, and it was held in Amsterdam, where I live. The company where I work, Werkspot, sponsored my ticket, so what else could I wish for?!

Well, actually I could wish for a good conference, and it was! Very experienced developers were speaking there: Vaughn Vernon, Udy Dahan, Nick Tune, Greg Young, Alberto Brandolini, Paul Raynes, the inevitable Eric Evans, and even Melvin Conway which is probably around 80 years old by now!!

I attended twelve talks and this post is about the three talks I found more interesting.

Some of the talks from 2016 are available on their YouTube channel, I suppose at some point they will make some of 2017 available as well.

Continue reading “DDD Europe 2017: The 3 talks I most enjoyed” →

PPPDDD.3 – Focusing on the Core Domain

An application is made of several components and sub-components, all of which are essential to the functioning of the application. However, there are components more important than others. Continue reading “PPPDDD.3 – Focusing on the Core Domain” →

PPPDDD.2 – Distilling the Problem Domain

Distilling the problem domain is about understanding the problem and its domain  in order to uncover what is relevant and create a model that reflects the domain and solves the problem at hand. In DDD, the activity of doing this is called in Knowledge Crunching. Continue reading “PPPDDD.2 – Distilling the Problem Domain” →

PPPDDD.1 – What is Domain Driven Design?

Building software that works is not difficult.

What is indeed difficult is to build software that lasts for many years, that keeps working despite the changes needed by the business, needed by the users, needed by new technologies. Building software that is permanently ready for change, and permanently and accurately reflects the business… thats the tricky part. Continue reading “PPPDDD.1 – What is Domain Driven Design?” →

DDD.16 – Large-scale structure

Segregating the domain into bounded contexts its a good start into maintainability, however if in every bounded context we have a different structure it can and will become cumbersome to understand the current bounded contexts and to further develop new bounded contexts.

For this reason, the team should rely on a simple generic structure to follow in every bounded context. This way, every developer in the team will be familiar with the global structure of every bounded context, making communication and collaboration easier between developers and teams.

Nevertheless, this does not mean the structure must be frozen. It can, and should, evolve as needed. Continue reading “DDD.16 – Large-scale structure” →

DDD.15 – Distillation

Distillation is the process of identifying the domain, decoupling it, isolating it, clarifying it and making it explicit, allowing us to focus on what is more relevant and having it maintainable.

There are a few techniques that can be used to distil a model.

Each of these techniques requires a successively greater commitment, but a knife gets sharper as its blade is ground finer. Successive distillation of a domain model produces an asset that gives the project speed, agility, and precision of execution.

e-book loc. 6509

Going through this distillation process has several benefits:

  • Makes the overall design explicit and known;
  • Distinguishes what is Core Domain from what is Generic Domain, reducing them to manageable sizes;
  • Focus the software evolution (development and refactoring) in what is more relevant at a given moment.

Continue reading “DDD.15 – Distillation” →

DDD.14 – Maintaining model integrity

When working in a large system, with a large model where we have several teams working on it, a section of the model will likely end up being interpreted, and adjusted in code, in different ways by the different teams.

These different interpretations and code adjustments will end up corrupting the model, leading to incoherent code and eventually bugs.

The best way to deal with this issue is to break the large model into smaller independent models. Breaking down a model is done by identifying bounded contexts and using context maps to identify their borders and relationships between them.

Continue reading “DDD.14 – Maintaining model integrity” →

DDD.IV – STRATEGIC DESIGN

As an application grows, the code quantity and complexity both grow with it. The quantity of developers and teams of developers also grow and system wide decisions have more impact and must be negotiated and decided by many people. These system wide decisions are very difficult to make because there are many points of view: design and politics intersect.

Continue reading “DDD.IV – STRATEGIC DESIGN” →