Starting with database design is actually a big pet peeve of mine. Sure, it's fine for some projects. Simple forms-over-data apps, stuff like that. But for anything more complex, anything that has a "domain" of logic, do not start with database design. Start with domain modeling. If you're taking business logic and putting it in code, then it's highly likely that the business users who define the logic flow do not think in terms of SQL or relational data at rest. They think in terms of logical interactions of concrete and abstract concepts.
As Eric S. Raymond said, "Smart data structures and dumb code works better than the other way around." Usually, when one starts with the database design, one creates a flat "dumb" data structure. Not dumb in the sense that it's a bad design, but in the sense that it has no built-in logic. It's flat and dimensionless. All of the intelligence would need to go into the code that uses it.
A rich domain model, on the other hand, incorporates business logic and concepts directly into the data structures. It's enhances the data itself with actual business intelligence, carrying that intelligence throughout the domain.
Now, this doesn't mean that you shouldn't think of persistence at all while designing the domain. But the persistence should be built to accompany the domain, not the other way around. Nilsson suggests starting with the domain and during the development of it take breaks to think and work on the persistence. This is because the domain model is really the core, but you'll need to evaluate any compromises on persistence to keep yourself realistic. Going for true persistence ignorance could dig yourself into some holes.
That all depends on what sparked the motivation to start a project in the first place. It could vary from sitting down and fleshing out detains of something that's been brewing amorphously in your mind for years, or sitting down and making a quick and dirty prototype to convince yourself that the genius idea you had that seemed so simple is actually quite a thorny bush that requires you to sit down and flesh out.
I never start with database design, as that's an implementation detail. I might not even want to use a database. I start with the functional design. What do I want it to do? Why? How? How does it do it differently from other approaches? Is the benefit enough to even bother doing it at all? You get the idea. Implementation design is tackled once I know clearly what I am doing and most importantly why.
That is very general but the first step is always to figure out and document what you want the application to do. Then I usually develop and ERD which defines the tables required to accomplish those functions along with the class structure that sits in front of those tables. Once those two big parts get done, it's usually pretty smooth sailing.
发布评论
评论（3）
从数据库设计开始实际上是我的一大烦恼。当然，对于某些项目来说这是很好的。简单的数据表单应用程序，诸如此类。但对于任何更复杂的事情，任何具有逻辑“域”的事情，都不要从数据库设计开始。从领域建模开始。如果您采用业务逻辑并将其放入代码中，那么定义逻辑流的业务用户很可能不会考虑 SQL 或静态关系数据。他们根据具体和抽象概念的逻辑相互作用进行思考。
正如埃里克·S·雷蒙德（Eric S. Raymond）所说，“智能数据结构和愚蠢代码比相反更有效。”通常，当人们开始数据库设计时，会创建一个平面“哑”数据结构。愚蠢并不是指它是一个糟糕的设计，而是指它没有内置逻辑。它是平坦的且无尺寸的。所有的情报都需要进入使用它的代码中。
另一方面，丰富的域模型将业务逻辑和概念直接合并到数据结构中。它通过实际的商业智能来增强数据本身，并将该智能传递到整个领域。
现在，这并不意味着您在设计域时根本不应该考虑持久性。但持久性应该与域一起构建，而不是相反。尼尔森建议从领域开始，在其开发过程中休息一下，思考并致力于持久性。这是因为领域模型确实是核心，但您需要评估对持久性的任何妥协，以保持现实。追求真正的坚持无知可能会让自己陷入一些困境。
Starting with database design is actually a big pet peeve of mine. Sure, it's fine for some projects. Simple forms-over-data apps, stuff like that. But for anything more complex, anything that has a "domain" of logic, do not start with database design. Start with domain modeling. If you're taking business logic and putting it in code, then it's highly likely that the business users who define the logic flow do not think in terms of SQL or relational data at rest. They think in terms of logical interactions of concrete and abstract concepts.
As Eric S. Raymond said, "Smart data structures and dumb code works better than the other way around." Usually, when one starts with the database design, one creates a flat "dumb" data structure. Not dumb in the sense that it's a bad design, but in the sense that it has no built-in logic. It's flat and dimensionless. All of the intelligence would need to go into the code that uses it.
A rich domain model, on the other hand, incorporates business logic and concepts directly into the data structures. It's enhances the data itself with actual business intelligence, carrying that intelligence throughout the domain.
Now, this doesn't mean that you shouldn't think of persistence at all while designing the domain. But the persistence should be built to accompany the domain, not the other way around. Nilsson suggests starting with the domain and during the development of it take breaks to think and work on the persistence. This is because the domain model is really the core, but you'll need to evaluate any compromises on persistence to keep yourself realistic. Going for true persistence ignorance could dig yourself into some holes.
这一切都取决于最初启动项目的动机是什么。它可能会有所不同，从坐下来充实多年来一直在你脑海中酝酿的东西，或者坐下来制作一个快速而肮脏的原型来说服自己，你的天才想法看起来如此简单，实际上是一个棘手的问题。需要你坐下来充实的灌木丛。
我从不从数据库设计开始，因为那是一个实现细节。我什至可能不想使用数据库。我从功能设计开始。我想要它做什么？为什么？如何？它与其他方法有何不同？这样做的好处是否足以让你费心去做呢？你明白了。一旦我清楚地知道我在做什么以及最重要的是为什么，就可以解决实施设计的问题。
That all depends on what sparked the motivation to start a project in the first place. It could vary from sitting down and fleshing out detains of something that's been brewing amorphously in your mind for years, or sitting down and making a quick and dirty prototype to convince yourself that the genius idea you had that seemed so simple is actually quite a thorny bush that requires you to sit down and flesh out.
I never start with database design, as that's an implementation detail. I might not even want to use a database. I start with the functional design. What do I want it to do? Why? How? How does it do it differently from other approaches? Is the benefit enough to even bother doing it at all? You get the idea. Implementation design is tackled once I know clearly what I am doing and most importantly why.
这是非常笼统的，但第一步始终是弄清楚并记录您希望应用程序执行的操作。然后我通常会开发 ERD，它定义完成这些功能所需的表以及位于这些表前面的类结构。一旦完成这两大部分，通常就会很顺利。
That is very general but the first step is always to figure out and document what you want the application to do. Then I usually develop and ERD which defines the tables required to accomplish those functions along with the class structure that sits in front of those tables. Once those two big parts get done, it's usually pretty smooth sailing.