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.
Category: Development
All development
DDD.13 – Refactoring toward deeper insight
When doing refactoring in DDD, we must keep our focus in 3 key aspects:
- The domain;
- Look at thing in a different way;
- Continuous discussion with the domain experts.
Continue reading “DDD.13 – Refactoring toward deeper insight”
DDD.12 – Relating Design Patterns to the Model
Design Patterns are very technical patterns in code, while Domain Patters are conceptual patters in the model.
STRATEGY
Some times, we have different ways in which we can perform an action, a process. In order to decide which strategy we are going to use at run time, we will eventually have a conditional.
In a naive approach we would have a method with as many conditionals as strategies to to perform the action, and all strategies coded directly in that same method. An approach which is a bit better, is to have a method for each different strategy, but still in the same class.
Using the STRATEGY design pattern, we create a class per each strategy algorithm. All of those strategy classes will implement a common interface so that the calling code can use either strategy class without caring which one it is actually executing. This will completely decouple the calling code from the concrete implementation of the different strategies.
The calling code will then use an ABSTRACT FACTORY to instantiate the appropriate strategy class according to a SPECIFICATION.
COMPOSITE
The composite pattern tries to simplify the usage of a complex structure of an object, by modelling that structure in as a tree where all elements are of the same type.
An example can be the products categories of a webshop. In this case, we have the categories completely decoupled from the products. It doesn’t really matter what products the category has inside. A category can have several categories inside, and those can have other categories in them, and so forth, so on, building the mentioning tree like structure where all elements have the same interface.
The example given by Eric Evans, is about travel routes, where each route is composed by an origin, a destination, and several smaller routes which are composed by even smaller routes and so on.
This post is part of a set of posts with my personal notes about all the chapters in the book “Domain Driven Design” by Eric Evans. I will do this as I read through the book, and take notes on the concepts I personally find more relevant.
DDD.11 – Applying Analysis Patterns
Analysis patterns are specialized, high level patterns who generically model a very well known and wide domain, they are not technical solutions.
These patterns allow us to cut down on the time spent in early stages of development, while doing knowledge crunching and trial and error iterations. They give us a head start, a solid advanced starting point from where to build what is specific to our domain, and anticipate consequences that are expensive if we have to discover them on our own.
Recommended reading:
“Analysis patterns: Reusable object models”
[Martin Fowler, 1997]
This post is part of a set of posts with my personal notes about all the chapters in the book “Domain Driven Design” by Eric Evans. I will do this as I read through the book, and take notes on the concepts I personally find more relevant.
DDD.10 – Supple Design
Supple, or elegant and flexible, design is a complement to Deep Modelling. While deep modelling is about digging out domain concepts with the domain experts, and reflecting those concepts in code, Supple Design is about building that code in a way that is easy to understand, modify and extend, in sum: code that is maintainable.
If we want to maintain speed of development as the project grows, we must design code that is a pleasure to work with, code that invites change. Otherwise the code will be a mess, where a small change can aggravate or break something: developers will dread to look at it, let alone work with it.
Eric Evans came up with a set of patterns that can help achieve this supple design.
DDD.9 – Making implicit concepts explicit
Implicit concepts are concepts that exist but , for some reason, the domain experts don’t talk about them explicitly. It takes some time until the developers actually realize the existence of those implicit concepts, by means of hints while discussing the model or at later stages, when several other concepts are already set in place.
Continue reading “DDD.9 – Making implicit concepts explicit”
Software Architecture vs. Code – by Simon Brown
Simon Brown talks to us about how, now days, we have many diagramming tools and concepts which some of us like to use, and sometimes are even imposed upon the developers by the corporations managers, who actually have no idea of technicalities and the usefulness or not of those diagrams. However, despite the tools and concepts we have, when we create a diagram of the architecture of a software program we are developing, most of the time it ends up not matching the actual code, we can not see the architecture in the code.
Continue reading “Software Architecture vs. Code – by Simon Brown”
Teams: building, managing, leading, performing
Years ago, after finishing my bachelor in computer science, while doing my specialization studies in teaching and, later on, while doing my masters in leadership and management, I had several subjects about psychology, management and leadership. Although I never excelled in human sciences, I always felt great interest in them and was a successful student at those subjects. The explicit concepts learned back then have since been fading away, leaving me with scattered implicit concepts, knowledge that I don’t really know where it came from any more, nor even if it has any validity.
Thus, I decided to refresh and update my knowledge, so I searched for some conference talks and articles about the subject, and decided to leave here my notes about what I’ve learned and re-learned, as well as a few opinions derived from my past team leading experiences.
Building and leading teams into performance is not an easy task, there are just way too many variables to be predictable. It’s after all, a human science. Nevertheless, there are many studies, theories, behaviour models, guidelines, questions and answers that can help us build and lead a team into performance.
Continue reading “Teams: building, managing, leading, performing”
DDD.8 – Refactoring toward deeper insight / Breakthrough
The third part of the book starts in chapter 8 and talks about refactoring.
Refactoring towards deeper insight has the objective of having a domain model that closely reflects the domain. This makes the software more in tune with what the domain experts think and to the users current and future needs.
Continue reading “DDD.8 – Refactoring toward deeper insight / Breakthrough”
DDD.7 – Using the language
This chapter is a long example of how project architecture may evolve.
There aren’t many new concepts approached, nevertheless, in the end of the chapter there are three interesting design patterns mentioned:
- Anti-corruption layer
- Enterprise segments
- Strategy
@hgraca 