Code in the Language of the Domain
来源:互联网 发布:淘宝开店论坛 编辑:程序博客网 时间:2024/05/17 04:47
Picture two codebases. In one you come across:
if (portfolioIdsByTraderId.get(trader.getId()) .containsKey(portfolio.getId())) {...}
You scratch your head, wondering what this code might be for. It seems to be getting an ID from a trader object, using that to get a map out of a, well, map-of-maps apparently, and then seeing if another ID from a portfolio object exists in the inner map. You scratch your head some more. You look for the declaration of portfolioIdsByTraderId
and discover this:
Map<int, Map<int, int>> portfolioIdsByTraderId;
Gradually you realise it might be something to do with whether a trader has access to a particular portfolio. And of course you will find the same lookup fragment — or more likely a similar-but-subtly-different code fragment — whenever something cares whether a trader has access to a particular portfolio.
In the other codebase you come across this:
if (trader.canView(portfolio)) {...}
No head scratching. You don't need to know how a trader knows. Perhaps there is one of these maps-of-maps tucked away somewhere inside. But that's thetrader
's business, not yours.
Now which of those codebases would you rather be working in?
Once upon a time we only had very basic data structures: bits and bytes and characters (really just bytes but we would pretend they were letters and punctuation). Decimals were a bit tricky because our base 10 numbers don't work very well in binary, so we had several sizes of floating-point types. Then came arrays and strings (really just different arrays). Then we had stacks and queues and hashes and linked lists and skip lists and lots of other exciting data structuresthat don't exist in the real world. "Computer science" was about spending lots of effort mapping the real world into our restrictive data structures. The real gurus could even remember how they had done it.
Then we got user-defined types! OK, this isn't news, but it does change the game somewhat. If your domain contains concepts like traders and portfolios, you can model them with types called, say,Trader
and Portfolio
. But, more importantly than this, you can modelrelationships between them using domain terms too.
If you don't code using domain terms you are creating a tacit (read: secret) understanding thatthis int
over here means the way to identify a trader, whereasthat int
over there means the way to identify a portfolio. (Best not to get them mixed up!) And if you represent a business concept ("Some traders are not allowed to view some portfolios — it's illegal") with an algorithmic snippet, say an existence relationship in a map of keys, you aren't doing the audit and compliance guys any favors.
The next programmer along might not be in on the secret, so why not make it explicit? Using a key as a lookup to another key that performs an existence check is not terribly obvious. How is someone supposed to intuit that's where the business rules preventing conflict of interest are implemented?
Making domain concepts explicit in your code means other programmers can gather theintent of the code much more easily than by trying to retrofit an algorithm into what they understand about a domain. It also means that when the domain model evolves — which it will as your understanding of the domain grows — you are in a good position to evolve the code. Coupled with good encapsulation, the chances are good that the rule will exist in only one place, and that you can change it without any of the dependent code being any the wiser.
The programmer who comes along a few months later to work on the code will thank you. The programmer who comes along a few months later might be you.
By Dan North
This work is licensed under a Creative Commons Attribution 3
- Code in the Language of the Domain
- Code: The Hidden Language of Computer Hardware and Software 总结
- The Histroy of language
- The language of learning
- Domain-Driven Design: Tackling Complexity in the Heart of Software
- The amazing efficiency of pointer in C Programming Language
- The BookList of Programming Language
- The Art of Assembly Language
- The key of C Language
- Programming in the Ruby language
- 血液本体:血液学领域的本体(The Blood Ontology-An Ontology in the Domain of Hematology)
- The view of the C language
- The view of the C++ language
- The origins of the English language
- The Development of the C Language
- the code of love
- a method to set the title of webpart in code
- the thinker of code complete -- general issues in using variables
- Choose Your Tools with Care
- Android系统定制之源码完美下载
- 有关PHP文档生成工具---PHPDocumentor
- 将pclint集成到vc++6.0和SourceInsight的方法
- 素数的求法
- Code in the Language of the Domain
- 第三次C程序上机报告
- 第三次c语言上机操作
- HDU 1003Max Sum
- Ubuntu12 安装JDK1.7
- Code Is Design
- hdu 3308LCIS 线段树 区间合并
- zoj 2576 Queen Collisions
- 黑马程序员_java的面向对象(对第六课静态..类的加载过程和单例的总结)