Software Layers
TL;DR: Please learn the currently accepted definitions terms so that you can use them correctly.
I am regularly amazed to see developers, whose primary job function is Applying Proper Names to Things, misapply new (to them) terms to well-known definitions. The most common example is probably calling your process agile whether or not it follows any of the principles. Who hasn't worked on a fixed bid, fixed scope, fixed date project and been told all along how "agile" the project is? The second you hear the phrase "scope creep," you know the customer isn't a priority and agile never made it to the table. While I am a huge proponent of XP (and I mean, by-the-book XP), I won't bore you with a rant on that topic.
What concerns me is Domain Driven Design. Domain Driven Design is a large subject that takes 100 pages to define quickly. I supposed this contributes to the misuse of the term.
Domain Driven Design defines 4 layers of an application: (User) Interface, Application, Domain, Infrastructure. Each of these layers contains business logic that is specific to a certain task. Each of these layers relies on the layers (plural!) below it.
What causes me the most heartburn is the lack of an Application layer in this model. Where do I encode use cases of this software? If they aren't easy to express in the Business classes, they seem to end up in the Presentation...or sometimes the Database.
The second thing that makes me uncomfortable is those Business classes. What purpose do they serve? Most often, they are placeholders for some future logic that we might discover someday but for now they just delegate directly to the Data layer. I will call your bluff on that one every single time. YAGNI and Dave Wheeler's famous quotation on indirection spring immediately to mind. I suppose could just be because I believe in the XP Value of Simplicity. Maybe it is because I have the Courage to change the software and it's architecture later if I find that it isn't meeting new needs. What ever it is, eliminate these pass-through classes and call the interface you really wanted to begin with.
In summary, please learn the definition of a term before you use it. Don't redefine the unfamiliar term to mean something you already know. Don't assume you understand a complex definition just because you have heard all the word in the term before.
I am regularly amazed to see developers, whose primary job function is Applying Proper Names to Things, misapply new (to them) terms to well-known definitions. The most common example is probably calling your process agile whether or not it follows any of the principles. Who hasn't worked on a fixed bid, fixed scope, fixed date project and been told all along how "agile" the project is? The second you hear the phrase "scope creep," you know the customer isn't a priority and agile never made it to the table. While I am a huge proponent of XP (and I mean, by-the-book XP), I won't bore you with a rant on that topic.
What concerns me is Domain Driven Design. Domain Driven Design is a large subject that takes 100 pages to define quickly. I supposed this contributes to the misuse of the term.
Domain Driven Design defines 4 layers of an application: (User) Interface, Application, Domain, Infrastructure. Each of these layers contains business logic that is specific to a certain task. Each of these layers relies on the layers (plural!) below it.
- The Interface is pretty simple to define. This is what is consumed by or visible to the user. It could be a rich desktop UI, a web site or a REST/WS-* service. The Interface layer uses the Application layer, Domain layer and Infrastructure layer to accomplish it's task.
- The Application layer is the coordinator of what to how. This thin layer expresses the rules of what the users want the application to do (use cases) in terms of the Domain. The Application layer is unlikely to contain any "reusable" code that could be put in another application.
- The Domain layer is where the invariants of the business are expressed. Entities, Value Objects and Services are part of this layer. This is likely to be a small nugget of solid gold in the heart of your application. This code has the most potential for reuse (if you believe in that kind of thing). The Domain should be Persistence Ignorant.
- The Infrastructure layer provides supporting libraries and state persistence mechanisms for the other layers.
What causes me the most heartburn is the lack of an Application layer in this model. Where do I encode use cases of this software? If they aren't easy to express in the Business classes, they seem to end up in the Presentation...or sometimes the Database.
The second thing that makes me uncomfortable is those Business classes. What purpose do they serve? Most often, they are placeholders for some future logic that we might discover someday but for now they just delegate directly to the Data layer. I will call your bluff on that one every single time. YAGNI and Dave Wheeler's famous quotation on indirection spring immediately to mind. I suppose could just be because I believe in the XP Value of Simplicity. Maybe it is because I have the Courage to change the software and it's architecture later if I find that it isn't meeting new needs. What ever it is, eliminate these pass-through classes and call the interface you really wanted to begin with.
In summary, please learn the definition of a term before you use it. Don't redefine the unfamiliar term to mean something you already know. Don't assume you understand a complex definition just because you have heard all the word in the term before.
Comments
Post a Comment