前言
从CSDN-知识库不再维护开始，整理此文，目的是补充自己软件工程方面的基础知识，主要包括：软件开发模式、面向对象设计原则、设计模式、系统架构设计、UML建模等相关内容。此为学习笔记，以学习为主线，辅以粗陋理解。大约在16年：刚正式踏入猿圈，会有些奇怪的设计想法，能把一些想法付诸实现；到17年：感觉想到什么，基本都能实现，但是不成体系；next年：了解了部分设计模式，开始可劲的生搬硬套；next年：回归到一个正常自我认识，不愿意看到以前写的… 后来有机会正儿八经写设计文档，却终于发觉自己有多知识枯竭…
在变的思路
固执、瓶颈、焦虑的碰撞。虽然能看到在进步，但明显的力不从心。焦虑的本源是，已经跳出了上一个舒适圈，却没有建立好新圈。记录201906-201909期间的一些反思：
- 发现自己在设计的过程中，会产生些相互矛盾的思路，不知道如何取舍，#纠结-循环进入同一个死胡同-纠结#,感觉浪费很多时间！怎么办？(后来给自己的答案基本是：基础不够扎实，像线程安全、拷贝效率、生套模式…都曾经绊过脚…)
- (201907x)慢慢发现，太固执于“统一处理了”，但限于自身Level，分析和架构达不到预期，所以会产生堆特殊处理的情况。当碰到此情况时，必须要适当考虑重构层次关系，如横纵向切换、增加中介等办法。
- 心太大，有时候基本思路还没有成型，就去考虑预留这预留那的，往往这些预留由于模块根基就不好，后期用到的可能性很低，甚至很可能是跑偏的。不得不反思，在一定level层级下时，三步并作两步走的行为，很有可能会导致徒劳。
- 至少是当前Level下，把思路快速实现为一定的伪代码，是必要的。首先这是一种验证手段，防止自己思路跑飞；思路会断片，更浪费的是有些东西即使写下来了，当时没有去用，很快就忘记自己想过写过！
- 去年初写的引以为豪的代码，现在再拿来看，一年的时间，发现看不懂了！惊讶啊，这明明是完全自己写的，却缕不清了。难道，难道这就是传说中，功能还算够强大，但是没有章法，最后无法维护的代码吗？（我想起了鸠摩智…）
- 在设计模式、架构设计的初学阶段，一知半解的时候，可能会过分的拘泥于形式，总想把当下的场景完全的套上一种“模式”，但往往走着走着，成了四不像。更有时，变的不知道如何写代码了，瞻前顾后无从下手。想象中的，关于它们的学习，该像张无忌跟张三丰学太极剑打败阿大一样…开玩笑…
- 对于那些打算重构，又有一堆理由没有去立即执行的地方。过上一段时间后，通常还会栽到那里，每个后一次逗比前一次耗费更多的时间去梳理和维护。
- 不要“为了复用而复用”主要体现在两个方向：为了形成一个复用类，而生硬的合成一个多职责的类；为了去重用一个已有的“并不完善的公共类”，去强行改造使用它的类。
- 看不下去，想大面积做重构，如果没有十足的把握和富裕的时间，建议不要尝试，否则本来的填坑操作，将变为酝酿更大的坑。
还是在挣扎，但相比上一阶段，感觉脑子开始转动了。期间（201910-202004）得空再次搬出来GOF设计模式进行通读，这次阅读体验大约是这样的：知识碎片有效串联的过程，飘飘然觉得任督二脉已通，看书中字字句句是真经典/精华。期间由于着手写一份设计说明书，也对UML、数据流、架构设计、设计模式使用等又积累了些经验。下面记录的是在这个时间段内写在笔记本上的一些反思：
- 在没有真正理解外观模式的含义时，常常意图“集中一些对外接口到一个类中”，有些内部处理函数甚至要传递好几层才能到达。出现上述情况时，首先考虑的不应该是"好看"，而是这种变态的现象是如何导致的？是不是设计的层次结构不合理，因为一个好的结构其产生的代码应该是温和的、功能层次明确清晰。另外，我们也没有必要为了减少接口个数，而费尽心机的找到两个语义上对称的合并它们，那常常适得其反影响代码质量和维护，相比成双成对或接口数量少，更该追求的是接口清晰明确！
- 在开始认真使用UML类图、活动动、数据流图进行设计后，发现了一件事情，那些拍脑袋划分的模块边界，它们中的部分甚至会在UML图中呈现孤立的状态，更不要谈什么高内聚。这也算是UML设计的一个额外的功能吧，画出图来，更容易的发现模块设计中的某些牵强之处…
- 20200220 因第一次用UML活动图，发现其中有个元素叫同步，感慨了五分钟，回想往事，我的软件设计之路走的太难了/(ㄒoㄒ)/~~尽管革命刚起步，但是相比那个妄想用基本流程图描述软件设计的菜0级，已经进步了不少！这主要得益于一个考试目标，当绞尽脑汁用已有的知识体系无法达成目标时，你需要系统的优化和扩展自己，串联碎片，打开新方向！
- 20200320 负责的软件总体设计说明书评审的时候，“评审员” 说了一筐不着边际的，但有一句却点醒了我，我的总体设计中缺乏对模块之间关系的描述。几经反思，本该出现在模块之间的关系，大都被我无知的放在了模块内部，相应的代码体现是一个模块库必须要包含它依赖的另一个模块库，相应的文档体现是关系被描述到了具体模块设计卷宗中。更是惭愧的发现，自己以前宣扬的那些模块独立性太扯淡，因为模块间甚有包含，怎敢荒唐的称低耦合。对模块间关系和模块链接方式的思考始于对中介者设计模式的深入思考.…
软件开发模式
在此之前，一直处于"一边开发一边设计"的level，哈，没想到这还是一种有名字的软件开发模式（^(oo)^ T_T）。来看看常见的软件开发模式，
软件设计方法
结构化程序设计方法之自顶向下逐步求精，https://blog.csdn.net/wenhlin/article/details/78641308
这句话该是在软考书上看到过… 查查 应该属于软件工程基础
面向过程设计、面向对象设计
面向对象设计模式
博主18年6月购咧《设计模式:可复用面向对象软件的基础》，惭愧，一年了，薄薄的一本书还没了结。
软件架构
五种常用的软件架构
https://blog.csdn.net/gbbqrglvir3dyi82/article/details/79226560
https://www.cnblogs.com/IcanFixIt/p/7518146.html
//这一章节可以单独开出来啦
《Software Architecture Patterns》看见不少博客上有对它的翻译。包含如下：
Layered architecture
Event-driven architecture
Microkernel architecture
Microservices architecture
Space-based architecture
《软件架构模式》-第三章 微内核系统结构
核心模块只拥有能使应用运行的最小功能逻辑。
如果这个模式解决了应用程序中的一个特定的问题而同时不能用这个模式来实现整个应用架构， 在这种情况下，你可以嵌入微内核架构模式到另一种模式（例如分层体系结构）。
整体敏捷度是能够快速响应不断改动的条件的能力。改动可以在很大程度上分割出来，并通过松散耦合的插件快速实施。一般来说，大多数微内核架构的核心系统会很快趋于稳定，由于它强大特性而且随着时间的推移仅仅需要很少的变化。
http://ifeve.com/talk-architecture/ 浅谈架构
http://ifeve.com/talk-arch-module/ 架构-模块化
领域驱动分层设计-各层的简单理解
DDD 极简教程
架构-分层/六边形
分层架构算是最常见和最受欢迎的一种架构，有一个说法是：“如果你不知道要用什么架构，那就用它。
DDD分层架构的三种模式 四层架构、五层架构和六边形架构
领域驱动设计
为什么要用领域驱动设计？
https://www.zhihu.com/question/57267198
不能讲领域驱动设计理解为某种具体的技术框架或工具，领域驱动设计的要诣是业务导向，技术服从和服务于业务。
看到这里，不得不回头看看上边，领域驱动和架构并不是一回事。（请在搞明白后，把架构一节中的关于领域驱动的内容拿下来）
DDD方法中并没有指定使用特定的架构。领域中的BC被封装为高内聚的模块，这种特性让DDD对架构并没有太大侵入性。架构可以应用于领域内部的结构，也可以包围着领域模型，系统中可以采用多种风格的架构。
https://www.cnblogs.com/xxzhuang/p/10634505.html 说的很恳切，有启发！
什么是领域驱动设计和怎么使用它
面向对象设计原则
软件设计模式六大原则-https://www.cnblogs.com/zhanghengscnc/p/8299459.html
面向对象的三个基本特征-https://www.cnblogs.com/autumn001/p/9036148.html
要想真正理解面向对象软件设计原则，个人感觉最好的办法就是拜读设计模式，设计模式真正懂了，所有的设计原则目标就都达成了。但是在学习步骤上，还是建议两个东西相辅相成的去学习，这样理解的更快些。
别跑太远了！！！
控制反转 （Inversion of Control，缩写为IoC），是面向对象编程中的一种设计原则，可以用来减低计算机代码之间的耦合度。其中最常见的方式叫做依赖注入（Dependency Injection，简称DI），还有一种方式叫“依赖查找”（Dependency Lookup）。IoC可以认为是一种全新的设计模式，但是理论和时间成熟相对较晚，并没有包含在GoF中。
控制反转IoC是Inversion of Control的缩写，是说对象的控制权进行转移，转移到第三方，比如转移交给了IoC容器，它就是一个创建工厂，你要什么对象，它就给你什么对象，有了IoC容器，依赖关系就变了，原先的依赖关系就没了，它们都依赖IoC容器了，通过IoC容器来建立它们之间的关系。
依赖倒置、控制反转和依赖注入等几个概念在程序员的头脑中,似乎并不是清晰的概念。在开发中如果总是将思维局限在如何实现这个层面上,将会给代码的撰写带来巨大问题。
IoC模式（依赖、依赖倒置、依赖注入、控制反转）
概念关联与区分
如设计模式、设计原则之间他们不是一个概念，但却是相辅相成的？相信架构与设计模式之间也是有着一定的联系的–待整理
UML设计
在进行软件设计的过程中，进行UML图的绘制，其必要性不再赘述。举一个简单的例子，我们拿出以前的设计实现，然后导出成类图，很容易我们就能发现其中的类关系问题，从而快速进行重构设计。
软件设计词汇
在GOF设计模式一书中，曾经看见过类似的说法：“模式名简介的描述了模式的本质，一个好的名字非常重要，因为它将成为你的设计词汇表中的一部分” “GOF-P232的相关描述”
架构设计、软件工程、UNL等相关书籍和资料，都能丰富你的设计词汇，让你更简单更准确的表述你的设计思路…
软件设实现的透明性
透明性的概念与实现原则-https://blog.csdn.net/ThinkHY/article/details/3614478
其他资料
软件设计的层次
https://wenku.baidu.com/view/34325359ad02de80d4d84084.html
这篇文章有一定的启发意义，可自行提炼整理下–
//转载自百度知道
一、透明性（transparency）
定义：在通信网中，不改变信号形式和信息内容的端到端传输。
二、透明性现象：
在计算机技术中，一种本来是存在的事物或属性，但从某个角度看似乎不存在，称为透明性现象。通常，在计算机系统中，低层次的机器级的概念性结构和功能特性，对高级程序员来说是透明的。
三、透明传输：
（1）数据链路层的透明传输
简单的说，透明传输就是发送方发送什么样的数据，不管数据传输过程是如何实现的，接收方将收到什么样的数据。更确切地说，所谓透明传输就是不管所传数据是什么样的比特组合，都应当能够在链路上传送。当所传数据中的比特组合恰巧出现了与某一个控制信息完全一样时，必须采取适当的措施，使接收方不会将这样的数据误认为是某种控制信息。这样才能保证数据链路层的传输的透明的。
（2）比特流的透明传输
TCP/IP结构体系中，物理层是靠比特流来传输的，比特流的透明传输是指实际电路传送后没有发生变化，因此，对于传送比特流来说，由于这个电路并没有对其产生什么影响，因此比特流就“看不见”这个电路。
四、eg：在QQ聊天中，表面上看QQ1直接与QQ2对话，而实际上是QQ1发送的数据分别通过传输层，网络层，数据链路层，物理层的传输被QQ2接收，QQ实际是与传输层直接对话，然而表面我们把其他各层当作不存在，这就是透明现象。