Domain Driven Design In Your Software Development Methodology

Sort of. But it's not anything new. It's been around as a bunch of strategies that have been used by developers. Today's read was this introductory article (An Introduction To Domain-Driven Design) at MSDN. DDD comes to interest mainly because my line of work as a software developer is primarily focused in the Financial Domain. Domain Driven Design is an approach in software development that revolves around the business domain. It expects you, the developer, to know and understand the business that your software is expected to support and build the software model to revolve around the business or domain.

From the article:

Domain-Driven Design (DDD) is a collection of principles and patterns that help developers craft elegant object systems. Properly applied it can lead to software abstractions called domain models. These models encapsulate complex business logic, closing the gap between business reality and code.

When I initially tried to understand how DDD would look like in real life, the first picture that came to mind was that it would probably be an application framework. But DDD is a little bit more specific and I'm still trying, in the midst of reading more about the topic, see what a real life example would look like.

One part of the article that was easy to relate to was that business terminology should reflect in our code too:

These domain experts use company- or industry-standard terminology. In DDD, this vocabulary is called the Ubiquitous Language. As developers, you want to understand this vocabulary and not only use it when speaking with domain experts but also see the same terminology reflected in your code. If the terms "class code" or "rate sets" or "exposure" are frequently used in conversation, I would expect to find corresponding class names in the code.

This is a pretty fundamental pattern to DDD. At first blush, the Ubiquitous Language seems like an obvious thing, and chances are a good that number of you are already practicing this intuitively. However, it is critical that developers use the business language in code consciously and as a disciplined rule. Doing so reduces the disconnect between business vocabulary and technological jargon. The how becomes subordinate to the what, and you stay closer to the reason for your job: delivering business value.

This approach kind'a clicks with me. As a software developer in the fininacials domain, sometimes we're required to directly interact with customers and understand their business. For large projects, you have Business Analysts who are thorough with the Business and serve as the interface between the development team and Business users. Once software developers understand the Business, they translate their understanding to working code. DDD attempts to provide organizational patterns that try to provide solutions to every aspect of business. These solutions work within contexts or what is referred to in DDD terminology, as Bounded Contexts which help us think of software as a portfolio of models that can be broken down into smaller chunks. Take any system in your organization and you will see that they can be broken down into many smaller parts. DDD trys to identify all these contexts and focuses your modeling effort within these contexts.

If you were to take a real life project that you might have worked on for an organization or a business, you will maybe have experienced such work when you had namespaces which were meant for some specific part of the system which were further broken down into classes that were more specific some set of tasks or operations (hence, it's sometimes easy to think of this whole thing as an application framework).

Domain models consists of:

Entities: These have a unique identity. Their attributes don't matter but their continuity consisting of lifetimes even beyond the system. This might be confused with class entities or the data models we are used to. But the difference is that entities in those respects can refer to multiple identities (Employee for instance, can refer to any number of people). A social security number would be a better example of an Entity. Hence, an object is differentiated by its identity

Value Objects: These describe the attributes of anything within the system. Attributes are internal states managed by the object and exhibit behavior. Objects can contain verbs that are associated with the attributes (Add Employee for instance).

Services: Sometimes operation cannot be completely associated with an object but may span across multiple objects. We then create operations that service these requirements. There is not internal state to this service and therefore the only task is to provide functionality for the domain. Services in no way replace operations that exclusively belong to an object.

Module: When the model is large and cpmplex, it becomes necessary to break down the model into modules. Complexity is reduced.

Aggregates: A group of associated objects which can be considered to be a unit with regards to data changes. The Aggregates can be logically separated between objects within it and those outside it.

Factories: These encapsulate knowledge required for object creation. Further, they are also useful for creation of Aggregates. When Aggregate is created, all associated objects are also aggregated. Essentially, it contains knowledge to create another object.

In short, what all this means is that in DDD, you create a model that is very much based on the domain and exposes all the concepts of the domain with enough room to further extend it if needed. Developers and Business users would use an Ubiquitous Language during the modeling process so that communication between software developers and domain experts will lead to the inclusion of domain concepts within the model. Once this model is created, the software developer would implement the model into code.

All this sounds very familiar if you have worked within particular industries. Working with BPM tools (such as PEGA PRPC), this approach sounds so familiar and it sounds like PRPC is based on DDD.

In my case, I think it will be useful to understand what this means for a software developer who concentrates in the Financial Domain. Over the pasts few years for the different projects I've worked in, I've noticed that many of the concepts and operations are very much the same though even at the same time, there are a lot of differences between customer to customer (for example, in banking, the "Know Your Customer" business requirement for all banks would pretty much be the same across customers with minor variations in operations and aspects relating to the bank). So where does DDD fit in all that? That is what I'm hoping to find out. I've also got in my to-do reading list Domain-Driven Design Quickly which is a minibook that you can either buy as print or get the ebook for free. The Official DDD Website is also one place I need to dig through a bit to see through examples. These should be ample resource to understand DDD even further and see if and how it relates to the Financial Industry where I work in.

It's quarter past two in the morning here and I'm calling it a day. Hopefully I should get some idea about this and see if it can make any difference in the way I work. I feel I've already employed much of the introductory part in my line of work though unaware of DDD guidelines. So now it's time to check the finer details of DDD.

Until next time,

Good night and Happy Programming!

I'm a slave of the programs and imprisoned in the grid. Please don't release me!

PS: I didn't use a spell checker so expect to find LOTS and LOTS of syntax and semantic errors in my post

Popular White Paper On This Topic

Related White Papers

2 Comments

I figured out, a long time ago, that you have to learne to speak in terms that your users can understand and that, to the extent possible, you have to learn to understand the terminology that your users use. However, just as there are dialects in normal human languages, there are dialects in the Ubiquitous Languages. Often, the particular dialect spoken at a particular company is tied to the history of the company ("Well, we've always called those that."), whether it is a universal term or not. In other cases, someone may have superimposed a "standard"dialect (almost like an ANSI Standard ;-) on top of the local dialect with the result that some local terms are used interchangeably with some Standard Terms ("Yeah, I know those are really called that but we've always called them this.").

That is why, also a long time ago, I developed the habit of wanting to confirm the connotative as well as the denotative meanings of the terms my users employ. For instance, one might think that a term as simple as Account Number could not be misunderstod. However, where I am currently employed, we have an Account Number for a Financial Institution but the Financial Institution uses the term Account Number for what our world knows as Loan Number. In dealing with some of our internal users, I have to make sure that I know which account number we are discussing.

Ubiquitous Language may work well as a goal; however, unless you have a means of enforcing a single set of terms for things, you will have to deal with the confusion of the dialects that are being spoken.

As I have been delving deeper into data warehouse requirements gathering and design, I keep finding re-enforcement for that statement. All too often, it seems, as businesses grow (and, especially, if they grow rapidly) nobody takes the time to create a Ubiquitous Language that is adopted throughout a department, much less the entire business. Everyone seems to think that everyone else is using a given term the same way that they are without bothering to ask, "When I say [fill in the blank], what does it mean to you?" That is how misunderstandings occur, arguments about "But you said . . . !" get started, interdepartmental feuds erupt, and projects (if not businesses) fail.

Pleasde note, the above is based upon my 40 years in the profession during which I have kicked around multiple industries and is solely IMHO. ;-)

Thanks for sharing from your experience and making a valid point on Ubiquitous Languages. You bring out an interesting point on enforcing standards even among business users. I guess it boils down to IT personnel being a domain experts in their respective fields.

I've pretty much come to the same realization that software developers have to endeavor understand the business as much as possible and talk like them too cutting out all the technical jargon out of it. Most projects have a Business Analyst for this part but I feel even Software developers can also be pretty good if not equally good. I can remember few of the many bugs logged being cases where the IT team had to correct a business user in the UAT phase since he got some aspect to the business rules wrong.

Disclaimer: Blog contents express the viewpoints of their independent authors and
are not reviewed for correctness or accuracy by
Toolbox for IT. Any opinions, comments, solutions or other commentary
expressed by blog authors are not endorsed or recommended by
Toolbox for IT
or any vendor. If you feel a blog entry is inappropriate,
click here to notify
Toolbox for IT.

George shares and discusses real-time software development insight, experiences and solutions in this blog. He enjoys talking ...
more

George shares and discusses real-time software development insight, experiences and solutions in this blog. He enjoys talking about anything that might be remotely related to IT and matters within every programmer's programming life. As he plays multiple roles and faces challenging situations in various stages of the SDLC in a global context, he's keen on developing a platform to exchange ideas, share insight and build a super network of developers and pundits.
less

Receive the latest blog posts:

Share Your Perspective

Share your professional knowledge and experience with peers. Start a blog on Toolbox for IT today!