Tag: Domain Driven Design

Views / Templates

This post is part of my Dev rules of thumb series. In them, I leave you with a poster with a few rules I follow for each concept, which you can print out and scatter around your office, and a brief explanation of what that pattern is about. You can also find a PDF of the poster at the bottom of this post, for better quality printing. However, please remember, a dev rule of thumb is a Principle with broad application that is not intended to be strictly accurate or reliable for every situation.

Views / Templates

When we think of a view, we usually relate it to the MVC pattern, created in the late 1970s by Trygve Reenskaug. However that was a long time ago and software development has changed, although mostly the context. Nowadays we create much larger and complex applications than in the late 1970s, and I dare say most of them are web applications, which was not the case at that time. So what we commonly call MVC in web-development nowadays, is not what was originally created by Trygve Reenskaug.

Continue reading “Views / Templates” →

Value Objects

This post is part of my Dev rules of thumb series. In them, I leave you with a poster with a few rules I follow for each concept, which you can print out and scatter around your office, and a brief explanation of what that pattern is about. You can also find a PDF of the poster at the bottom of this post, for better quality printing. However, please remember, a dev rule of thumb is a Principle with broad application that is not intended to be strictly accurate or reliable for every situation.

Value Objects

Value objects are sometimes confused with DTOs, however, while DTOs are simple data containers with no significant logic, Value Objects are a “thing”, they represent a cohesive concept; they can wrap multiple attributes and the logic associated with them to fully encapsulate that single concept.

Continue reading “Value Objects” →

DTO – Data Transfer Objects

This post is part of my Dev rules of thumb series. In them, I leave you with a poster with a few rules I follow for each concept, which you can print out and scatter around your office, and a brief explanation of what that pattern is about. You can also find a PDF of the poster at the bottom of this post, for better quality printing.However, please remember, a dev rule of thumb is a Principle with broad application that is not intended to be strictly accurate or reliable for every situation.

DTOs

Data Transfer Objects (DTOs) are objects used only to pass some data around as a whole, as opposed to several individual variables.

Continue reading “DTO – Data Transfer Objects” →

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” →

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” →