- MARTIN FOWLER DOMAIN DRIVEN DESIGN UPGRADE
- MARTIN FOWLER DOMAIN DRIVEN DESIGN SOFTWARE
- MARTIN FOWLER DOMAIN DRIVEN DESIGN CODE
If we extract the data fields from the business logic in order to support the different operations we need to do to the data, then we may be left with POJOs or DTOs objects that Martin Fowler describes as 'hateful' and 'things our mothers told us never to write' (PoEAA again). We are caught between a rock and a hard place. It's great if we can do this and have all the logic and validations associated with a given domain class living within the class, but as we have seen above the reality is often that the data needs to be stored, retrieved, cached and so on, and the business logic does not. Martin Fowler mentions "A domain model mingles data and processes, has multi-valued attributes and a complex web of associations, and uses inheritance." (PoEAA) We are taught to nevertheless bind the two together and build rich domain models. They serve different needs and are handled in different ways.
MARTIN FOWLER DOMAIN DRIVEN DESIGN CODE
So our code has these two aspects - data and business logic - and they are quite different. Again we need to add information to the domain model in order to use the data in other places or with other tools. (Keys in Hazelcast need to provide identity without considering the content of the data). In this example a version is added to the data to assist with optimistic locking in the database.Īs a second example, if I wish to store the data in a class into an in-memory data grid, such as Hazelcast, I need to transfer the data into an object which can be serialized and which has a unique key. As part of that process the data fields are first wrapped in another class, and then transformed into a JPA entity before being persisted. The Product class contains data fields and these can be persisted to a database. The business logic pertaining to the Product class can exist within the class itself and the business logic for the domain can be tested in isolation. "Product" is a class existing within a domain model. It does not need to be transformed in different ways to suit its different usages.
MARTIN FOWLER DOMAIN DRIVEN DESIGN UPGRADE
(Or never changes without an upgrade of the application, at least). It is never persisted as an entity in a database or in a file because it never changes. The business logic, on the other hand always lives as part of the domain model, is often attached to a specific class and operates on a specific set of data. Often they don't only exist as part of the domain model but they have these additional lives elsewhere. They might be converted into JSON and used in an external web service call. As they represent data their life goes beyond this also - the class might be persisted to disk or database or be placed into an in-memory cache. Methods within the class operate on them and change their values, they validate them and ensure the class as a whole is always consistent and makes sense. They will generally exist as part of a domain class. This is summarized in the table below.Ĭonsider how the data fields in a micro-service class might be used. Software needs to use both aspects together to produce an application or microservice, but in many senses, these two things are quite different and have different requirements and life cycles.
MARTIN FOWLER DOMAIN DRIVEN DESIGN SOFTWARE
In domain-driven software development, there is a similar situation: there are data fields and structures, (which we might liken to the physical pieces of the game), and there is the programming logic, or business logic, which governs how the data fields can be changed and manipulated. They are both needed together to play the game. These two aspects - the physical and the non-physical - have different properties, different life cycles, and are used in different ways. There are two different aspects of what's happening here which I'd like to draw your attention to there are the physical elements of the game - the board, the counters, the money, and so on - which live in the box most of the time, and there are the non-physical elements such as the rules, which as mentioned, generally live in our minds. We put out the board, place the counters and cards, and begin to play the game. There's a rule book too in the box but that is largely left to the side we know the rules already. Of course, it comes with the board and counters, the cards and the money. Sometimes with my children, when the nights draw in, we play board games to pass the time. Proviso: I largely refer to Java implementation aspects in this article but the principles are transferable to other languages