`
stephen80
  • 浏览: 105379 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

放弃ddd ,根本的prefactoring

阅读更多
呵呵,
认真读完prefactoring .感觉 jolt award 确实牛。ddd 根本没有进去名单,也有一定道理。
所以,beautiful code 也要好好读。

plan
whats you plan?
1. write product market report:virtual,search
2. read beautiful code
3. working pipes

    < Day Day Up >    

A.1. Guidelines
The following subsections list the guidelines that are introduced in this book. Some guidelines are repeated in multiple chapters, as they can be applied in multiple contexts.

A.1.1. Big Picture


Don't Reinvent the Wheel

Look for existing solutions to problems before creating new solutions (Chapter 2).



Think About the Big Picture

Decisions within a system should be congruent with the big picture (Chapter 3).



Document Your Assumptions and Your Decisions

Keep a journal for retrospectives (Chapter 3).



Don't Repeat Yourself (DRY)

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system (Chapter 3).



Plan Globally, Develop Locally

Incremental implementations should fit into a global plan (Chapter 4).

A.1.2. Extreme Abstraction


Splitters Can Be Lumped More Easily Than Lumpers Can Be Split

It is easier to combine two concepts than it is to separate them (Chapter 2).



Clump Data So That There Is Less to Think About

Clumping data cuts down on the number of concepts that have to be kept in mind (Chapter 2).



When You're Abstract, Be Abstract All the Way

Do not describe data items using primitive data types (Chapter 2).



Strings Are More Than Just a String

Treat String as a primitive data type. Describe attributes with abstract data types, instead of as Strings (Chapter 2).



Never Let a Constant Slip into Code

Use a symbolic name for all values (Chapter 2).



To Text or Not to Text

Use text between programs, not within programs (Chapter 5).



If It Has Collection Operations, Make It a Collection

Collections separate object usage from object storage and hide implementation of aggregate operations (Chapter 5).



Don't Change What It Is

Create new terms rather than trying to apply new meanings to current terms (Chapter 12)

A.1.3. Extreme Separation


Adapt a Prefactoring Attitude

Eliminate duplication before it occurs (Chapter 3).



Don't Overclassify

Separate concepts into different classes based on behavior, not on data (Chapter 5).



Place Methods in Classes Based on What They Need

If a method does not require instance data, it should not be a member of the class. Conversely, if all the method requires is the instance data, it should be a member of the class (Chapter 6).



Honor the Class Maxims

Make loosely coupled cohesive classes (Chapter 6).



Do a Little Job Well and You May Be Called Upon Often

Methods and classes that perform specific jobs can be reused more often (Chapter 6).



Separate Policy from Implementation

Keeping the what separated from the how makes the what more readable and maintainable (Chapter 6).



Separate Concerns to Make Smaller Concerns

Split responsibilities among multiple methods and multiple classes to simplify each method and class (Chapter 7).



Test or Production; That Is the Question

Place all test-only methods in a test interface (Chapter.



Build Flexibility for Testing

Plan for flexibility in your design to allow for ease of testing (Chapter.



Decouple with Associations

Association classes decouple the two classes being associated (Chapter 9).



Split Interfaces

Split a single interface into multiple interfaces if multiple clients use different portions of the interface (Chapter 10).



Do a Little and Pass the Buck

Add proxies to interfaces to add functionality (Chapter 11).



Business Rules Are a Business unto Themselves

Keep business rules separate from other logic (Chapter 13).

A.1.4. Extreme Readability


A Rose by Any Other Name Is Not a Rose

Create a clearly defined name for each concept in a system (Chapter 2).



Prototypes Are Worth a Thousand Words

A picture of an interface, such as a screen, can be more powerful than just a description (Chapter 2).



Communicate with Your Code

Your code should communicate its purpose and intent (Chapter 3).



Explicitness Beats Implicitness

Being explicit reduces misinterpretation (Chapter 3).



Declaration over Execution

Declarative-style programming can provide flexibility without code changes (Chapter 5).



Use the Same Layout to Get the Same Layout

Use templates or scripts for classes and methods to create consistent logic (Chapter 10).



The Easiest Code to Debug Is That Which Is Not Written

Never write functionality that already exists in usable form (Chapter 11).



Use the Client's Language

Use the client's language in your code to make it easier to compare the logic in the code to the logic of the client (Chapter 13).

A.1.5. Interfaces


Create Interface Contracts

Design with well-defined interfaces and enforce the contracts for those interfaces (Chapter 3).



Validate, Validate, Validate

At each interface, validate that the input matches the contract (Chapter 3).



Test the Interface, Not the Implementation

Use the contract of the interface to develop the functional tests, not the implementation behind it (Chapter 10).



Adopt and Adapt

Create the interface you desire and adapt the implementation to it (Chapter 11).



Don't Let the Cold Air In

With interfaces exposed to the outside world, ensure that input validation and logging occurs (Chapter 14).

A.1.6. Error Handling


Decide on a Strategy to Deal with Deviations and Errors

Determine for your system what are deviations and what are errors, and how to deal with both (Chapter 3).



Report Meaningful User Messages

Error messages should be reported in the context of what the user can do about the error, instead of in terms of what the underlying error is (Chapter 3).



Never Be Silent

If a method encounters an error, it should report it, not remain silent (Chapter 6).



Consider Failure an Expectation, Not an Exception

Plan how operations should respond to failures (Chapter 13).

A.1.7. General Issues


Don't Speed Until You Know Where You Are Going

Make the system right, before you make it fast (Chapter 3).



The Spreadsheet Conundrum

Recognize when you are making the row/column decision (Chapter 3).



Consistency Is Simplicity

A consistent approach to style and solutions can make code easier to maintain (Chapter 3).



If It Can't Be Tested, Don't Require It

Every functionality requirement, whether formally or informally stated, should have a test created for it. If you cannot test a requirement, there is no way to determine whether you have met it (Chapter 4).



Plan for Testing

Developing test strategies in advance can lead to a better design (Chapter 4).



Figure Out How to Migrate Before You Migrate

Considering the migration path might help you discover additional considerations in other areas of the design (Chapter 7).



Know Who It Is

Determine uniqueness criteria for objects that should be unique (Chapter 7).



Perform a Retrospective After Each Release

Examining your design and how you created it can help in the next release (Chapter.



Nothing Is Perfect

There is usually a better solution, but you can stop with good enough (Chapter.



See What Condition Your Condition Is In

Use state-based analysis to examine object behavior (Chapter 9).



Get Something Working

Create something basic before adding refinements (Chapter 10).



Plan Your Logging Strategy

Determine where and how you are going to log (Chapter 11).



More Is Sometimes Less

Use a prewritten module with more features than you currently need and adapt it to your current needs (Chapter 11).



Be Ready to Import and Export

Data should be available for use outside the system via a well-defined data interface (Chapter 12).



Avoid Premature Generalization

Solve the specific problem before making the solution general (Chapter 14).

A.1.8. Security


If You Forget Security, You're Not Secure

Security should not be an afterthought. Consider it during all phases of development (Chapter 4).



Consider Privacy

Systems need to be designed with privacy in mind (Chapter 13).

A.1.9. General Objects


Avoid Premature Inheritance

Inheritance needs time to evolve (Chapter 5).



Think Interfaces, Not Inheritance

Interfaces provide more fluidity in the relationships between classes (Chapter 6).



Overloading Functions Can Become Overloading

By using unique names, functions can be more self-describing (Chapter 6).



When in Doubt, Indirect

Indirection, using either methods or data, adds flexibility (Chapter 11).

  

分享到:
评论

相关推荐

    DDD领域驱动设计学习框架简介PPT

    领域驱动设计(DDD)是一种软件开发方法,由Eric Evans在其同名著作《领域驱动设计》中提出。DDD致力于解决复杂业务系统的开发问题,通过将业务领域专家与开发人员紧密合作,将复杂的业务逻辑转化为可执行的软件模型...

    DDD领域设计模式代码案例

    DDD(领域驱动设计)是一种软件开发方法,它强调以业务领域为中心进行系统设计,通过将复杂的业务逻辑转化为可理解的模型来提升软件质量。在Java环境下,DDD可以帮助开发者更好地理解和实现业务逻辑,提高代码的...

    【推荐】DDD领域驱动设计&中台实践资料合集(20份).zip

    DDD领域驱动设计&中台实践资料合集,共20份。 DDD促进传统架构微服务转型 化繁为简--DDD驱动复杂业务软件架构的演进 基于FP的DDD实践 基于DDD的领域建模中的模版和工具实践 架构分层模型适配 金融支付系统的改造之...

    DDD分层架构参考代码目录结构

    《DDD分层架构及其在微服务中的应用》 DDD(Domain-Driven Design,领域驱动设计)是一种软件开发方法,强调以业务领域为中心进行系统设计。其分层架构模型是DDD的核心设计模式,它将系统分为用户接口层、应用层、...

    领域驱动模型(DDD).zip_ddd_领域模型_领域驱动_领域驱动设计

    领域驱动设计(Domain-Driven Design,简称DDD)是一种软件开发方法,它强调通过深入理解和建模业务领域来驱动软件的设计和开发。DDD的核心思想是将复杂的业务逻辑转化为可操作的软件模型,以此来提高软件的可维护性...

    DDD领域驱动设计和中台实践资料合集25篇.zip

    DDD实战,领域驱动设计 DDD在旅游电商架构演进中的实践 Every Entity as A Microservice - 领域驱动设计DDD 分享我对领域驱动设计(DDD)的学习成果 化繁为简--DDD驱动复杂业务软件架构的演进 基于DDD的领域建模中的...

    大白话领域驱动设计DDD视频教程

    第1章 初步了解DDD 课程介绍 抛开杂念,看看传统三层CRUD编程方式 DDD领域驱动设计到底是什么? DDD和传统三层优劣势比较 DDD在国内现象是个什么情况? DDD从战略设计到战术设计概览 第2章 领域分析模型 核心域,...

    基于DDD和微服务中台架构与实现

    【基于DDD和微服务的中台架构与实现】是一本深度探讨现代企业IT架构的书籍,作者欧创新和邓頔结合实践经验,阐述了如何利用领域驱动设计(DDD)和微服务架构构建灵活且高效的中台系统。以下是该书涉及的主要知识点:...

    ddd.rar_ddd_ddd linux_ddd manual_linux_linux ddd

    本压缩包文件“ddd.rar_ddd_ddd_linux_ddd_manual_linux_linux ddd”显然是ddd调试器在Linux平台上的相关资源,特别是其用户手册。 ddd的主要功能包括查看和修改内存,单步执行代码,设置断点,查看调用堆栈,以及...

    ddd.rar_www.03ddd_www.DDD89.com

    标题中的"ddd.rar_www.03ddd_www.DDD89.com"表明这是一个压缩文件,可能包含了某个项目或资源的代码、文档等,而URL部分可能是发布者或来源的标识,但具体网址已无效。 描述中提到的是一个89S52微控制器与射频卡...

    DDD领域驱动设计&中台实践资料合集(20份).zip

    DDD领域驱动设计&中台实践资料(20份): DDD促进传统架构微服务转型(42页).pdf DDD在旅游电商架构演进中的实践(47页).pdf DDD实践中的那些坑(28页).pdf DDD的为与不为(25页).pdf Every Entity as A ...

    设计的秘密:DDD落地最佳实践与实战

    "设计的秘密:DDD落地最佳实践与实战" 本资源摘要信息主要关注Domain-driven design(DDD)的设计理念和实践,旨在帮助开发者更好地理解和应用DDD在软件开发中的重要性。 DDD的优势 DDD的主要目的是为了解决软件...

    DDD实战篇:分层架构的代码结构

    不同于其它的架构方法,领域驱动设计DDD(DomainDrivenDesign)提出了从业务设计到代码实现一致性的要求,不再对分析模型和实现模型进行区分。也就是说从代码的结构中我们可以直接理解业务的设计,命名得当的话,非...

    DDD 微服务落地实战视频教程

    《DDD 微服务落地实战视频教程》是一套全面解析领域驱动设计(Domain-Driven Design,简称DDD)在微服务架构中的应用的课程。这套教程共包含21个章节,旨在帮助学习者从理论基础到实战技能,逐步掌握如何在实际项目...

    最新领域驱动设计(DDD)资料合集(23份).zip

    最新领域驱动设计(DDD)资料合集,共23份。 金融支付系统的改造之路 化繁为简--DDD驱动复杂业务软件架构的演进 基于DDD的领域建模中的模版和工具实践 基于FP的DDD实践 架构分层模型适配 可视化的遗留系统微服务...

    【推荐】张逸-DDD聚合工作坊

    【推荐】张逸-DDD聚合工作坊是一份深入探讨领域驱动设计(Domain-Driven Design,简称DDD)的专题资料,由知名专家张逸在IAS2019演讲中分享。这份29页的PDF文件是关于如何有效地运用DDD方法论进行软件开发的实践指导...

    linux下ddd工具的使用

    Linux操作系统中的DDD(Data Display Debugger)是一个图形化的调试器前端,它使用了LessTif或Motif用户界面工具包来提供交互式的调试环境。DDD的主要功能是帮助开发者调试C、C++、Java、Perl、Python等语言编写的...

    单纯的DDD代码

    **领域驱动设计(Domain-Driven Design,简称DDD)**是一种软件开发方法,它强调以业务领域为中心进行系统设计,将复杂的业务逻辑转化为清晰的模型。DDD的核心思想是将业务领域专家(Domain Experts)的知识转化为...

    DDD调试器下载

    DDD(Debugger for X)是一款强大的、跨平台的源代码级调试器,专为那些寻求图形用户界面(GUI)以提高调试效率的开发者设计。DDD基于GNU的gdb、dbx等命令行调试器,提供了直观易用的可视化界面,使得调试C、C++、...

    ddd.rar_ddd474.com

    本资源"ddd.rar_ddd474.com"提供了一种实用的方法来解决这一问题,主要总结了三种常用的技术。下面我们将详细探讨这三种方法。 1. **使用公共静态变量**: 公共静态变量是一种简单直接的方式,可以在程序的不同...

Global site tag (gtag.js) - Google Analytics