两个月后，我的主管给我们做了一次分享，就拿了一张ppt来讲，它外面包含了范围的实体，以及实体之间的关联关系，一下子我就知道了整个业务是怎样玩转的。模型的作用就是简化人对事物的看法，假设一末尾我们就堕入到代码细节中，很美观到业务的全貌，而且代码是为了完成业务才能，当你知道了业务之后，再去看代码就会快得多。
2.一致看法在公司里，有研发、产品、运营、测试……，当我们在一同交流的时分，大家默许的言语是不一致的，开发常常讲怎样操作这张数据库表，产品常常讲业务形式……这就招致大家的看法并不一致。
那是一个早晨，刚和交互同窗确认完交互流程后，突然她问了一个成绩：把相似的页面让卖家移到同一个文夹中，这个好完成吧？听完后告知不能，交互同窗一听说这很合理呀，怎样完成不了？末尾给她讲了下现有的舷流程，发现她听得一脸懵逼，马上发现成绩了，我是用开发的言语在描画成绩，立马换了一种方式，找了一支笔和一张纸，给交互同窗画了我们的范围模型是什么，业务虚体之间的交互是怎样的，一讲完后，交互同窗马上明白了为什么不能完成的缘由所在了。
3.指点设计有的同窗觉得范围建模偏空泛，比较虚，其实除了可以简化看法和一致看法外，范围建模还能够指点代码设计，比如下面举的店铺导航Tab的例子，笔者就是经过范围建模来设计的，虽然它是一个小的需求，并不阻碍范围建模的运用。在下图中，可以明晰的看到，导航栏包含了若干个Tab，一个Tab包含规格信息和点击操作信息。把这个业务形式画出来之后，对应的代码中也会有下面的概念，理想与代码之间存在映射关系，模型即代码，代码即模型。假设你的模型不能反映理想，模块只能算是一个花架子，范钢教员对此总结了三句话：理想有什么事物，对应有什么对象；理想事物有什么行为，对应对象有什么办法；理想事物有什么联络，对应对象有什么关联。
关于设计准绳，普通我们谈判到SOLID，它包含了五个设计准绳：
单一职责准绳：A class should have one, and only one, reason to change，一个类只能由于一个理由被修正。
开闭准绳：Entities should be open for extension, but closed for modification，对扩展开放，对修正封锁。
里氏交流准绳：Functions that use pointers of references to base classes must be able to use objects of derived classes without knowing it，子类可以交流父类。
接口隔离准绳：A client should not be forced to implement an interface that it doesn’t use，不能强迫客户端完成它不运用的接口，应该把接口拆的尽能够小。
依赖倒置准绳：Abstractions should not depend on details. Details should depend on abstractions，笼统不依赖于细节，而细节依赖于笼统。
2.为什么要有设计准绳我们对SOLID准绳基本上听说过或许了解过，但为什么要有这些设计准绳呢？为了回答这个成绩，我们从目的往下推导下。软件开发的目的是高内聚、低耦合，这句挂在嘴边的话，发现很难权衡，比如要回答：什么样的叫高内聚？什么样的叫低耦合？高内聚要高到什么水平？低耦合要低到什么水平？这四个成绩并不太好回答。
反过去想想，假设我们的代码不是高内聚和低耦合的会怎样？也即是低内聚和高耦合的场景。假设代码是低内聚和高耦合，则会出现修正一个逻辑，会招致多处代码要修正，这个并不是我们希望看到的，尤其在修正原有的逻辑，很容易出现bug，比如笔者之前修正一个成绩，改了另外一处的规则，看起来是没有成绩，结果影响到了一个业务方，这也是为什么开闭准绳提出对修正封锁的缘由，修正原有的逻辑是有风险的。
理想的状况是修正只限定在某个部分范围内，这样影响的范围有限，因此我们要求逻辑要单一，不要包含多个职责。再往下思索下：为什么我们要修正呢？除了原有逻辑有bug要修复、代码重构外，一个重要的缘由是需求发作了变化，是变化招致我们要对原有的逻辑停止修正。假设没有修正的场景，也就没有所谓的高内聚、低耦合之说了。因此设计准绳的底层逻辑就是让软件可以较好地应对变化，降本增效。
3.如何落地实际设计准绳只是一个指点的方针，离落地实际还有很大的一段距离，就像有些同窗说设计准绳我懂了，但我依然运用不到。实践上这个成绩的本质还是对设计准绳的底层逻辑没有了解，没有洞察出变化关注点，怎样处置这个成绩呢？设计形式给出的答案：找到变化、封装变化。
当调用的接口有不同的完成时（入参、出参、接口都不相反），需求笼统出一层防腐层，怎样去完成呢？接上去辨别看2个案例，这2个案例的侧重点不一样，一个是偏行为的笼统，一个是偏结构的笼统。
1.店铺品牌查询店铺需求查询店铺品牌信息，但是Lazada和AE的接口是不一样的，怎样笼统防腐层呢？
首先最复杂的方案很容易想到，就是定义一个接口，然后有两个完成。它的优点是层次复杂，大家基本看了就懂。它的缺陷也是清楚的，在两个完成类中，职责不一单一，承当了两个职责：一个是完成店铺品牌的查询，另一个是数据转换。
依据方案一提到的缺陷，很容易想到运用适配器形式，将之前的类拆成两个类：一个类是调用对应的品牌效劳；另一个类做数据适配转换。不过此时的方式还有一个缺陷就是在国际化场景下，要思索多租户之间的隔离，比如Lazada有多个站点，如何完成更细粒度的差异呢？方案三基于这些的思索就产生了。
方案三是引入了多租户框架，可以支撑多租户场景。
(责任编辑：admin)