Domain Driven Design? What's that? Another design pattern? 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!