《阿甘正传》中，阿甘开始了不停地跑步，一段时间后，后面就有了很多追随者一起跑，他们为什么跑哪？
阿甘：我也不知道，只是想跑而已。
追随者：感觉这样做是有意义的，而且阿甘也还在前面领跑。
类似地，一开始我也不知道DDD是什么，但当发现大家都在提DDD、都在学DDD的时候，我也像跟跑者一样不由自主地加入了前行：既然有大牛提出了DDD，既然那么多人趋之若鹜，那么肯定有可取的地方。
然而，有一天，阿甘停止了跑步，他不想跑了，追随者遇到了一个问题：我们还要跑么？当我们在学习DDD的过程中，感觉学而不得的时候，可能也会问：我们还要学么？这的确引人深思。
本文基于工作经验，尝试谈谈对DDD的一些理解，希望能够更好地探寻学习DDD的意义。
关注DDD的价值
无论做业务，还是做平台、中台，大家常常会被交错复杂的业务逻辑、晦涩耦合的业务代码搞得心力憔悴。我想，大家对DDD的追求，也是对轻松支撑业务发展的诉求，在探寻有没有合适的理论可以改善现状。毕竟，美好生活，共同向往。
▐ 现状：分层支撑机制
我们选择各种框架、进行各种组织设计，核心是为了提高生产效率。但如果业务逻辑都是 case by case 地进行实现、缺少复用，那么研发成本是非常高的、投入周期也会非常长。
为了增加复用、缩短业务的落地时间，就需要很多通用的能力、产品。在我们的交付过程中，主要有两个层次：
基础能力：相对原子的能力是基础（域）能力，这个可以较好地支持业务定制。由于比较基础，表达的产品能力范围也是很大的。但是，一个完善的产品需要串联的基础能力是非常多的，串联的成本也是非常高的。
平台产品：基础能力的通用性，意味着缺少对场景的理解，缺少了进一步提升生产效率的“基因”。所以在交付的时候，会基于一些高频场景进行抽象，形成平台的产品能力，争取做到“拆箱即用”。业务基于“平台产品”这层进行定制的时候，理解成本会大大减少。
分层支撑框架
▐ 腐化：业务逻辑渗透
このレベルは非常に優れているように見えます。初期段階では、歴史的な負担がないため、確かに特定の生産効率を向上させることができ、これは能力自体の利点です。しかし、時が経つにつれ、ビジネスアクセスの増加に伴い、企業同士が影響し合うようになり、研究開発に対する抵抗も増大しています。
研究開発効率が低下する重要な理由は、私たちが依然として「事業をどれだけ速く、どれだけ早く実行できるか」というロジックに従って関連作業を行い、水に遭遇したら橋を架け、山に遭遇したら穴を開け、そしてその後、目的地に直接行き、情報を伝達し、データベースフィールドの操作を行います。
このようなプロセスは、「クリーンなカーネルを確保しながら、ビジネス シナリオを通じてプラットフォームの機能を強化したい」という私たちの当初の意図に反します。機能は、比較的多数のユース ケースと比較的完全な考え方に基づいて抽象化される必要があります。これは水平方向の統一的な見方であり、より深い理解が得られます。ただし、垂直方向の配信では、問題をより垂直方向に処理できるようになり、多くの場合、単なる「覗き見」が可能になります。納期や業務ノードの制約のもとでは、より包括的かつ深く考えることは難しく、より一般的な設計を行うことは困難です。
▐ビジネス 防御: プラットフォームフレームワークガード
では、なぜ DDD に注目するのでしょうか? DDD がソフトウェアの複雑さの中核である「問題領域」に直接的に影響を与えるとしても、それは依然として比較的抽象的なものである可能性があります。具体的には、これは私たちが追求する価値観 (長期的な生産性の向上) と実際に一致しているためです。
分野を細分化し、プロフェッショナルな人やモノを育てる：DDDの核心は、各分野をよく理解してパッケージ化し、ビジネス要件を分解して適切な場所に配置することであるため、そのような分解と沈殿を通じて、インプットが長期にわたって達成できるドメインを確保します持続可能な発展を実現し、競争力を形成します。
変更可能なものに依存しないメカニズムの保証: DDD は実際に多くの共通のスキルと経験を要約しており、そのような実装をより決定論的にすることができます。ドメイン エンティティを制御する集約ルートの機能、境界付きコンテキストの相互作用戦略、ドメイン コアの抽象ステータスなど、一度尊重して確認することを選択すると、組織的なコード構造に陥る可能性があります。合意形成が図られており、人事異動などによって大きく変動することはありません。
DDDへのこだわりは「職人気質」へのこだわりに例えられますが、DDDへのこだわりはビジネス理解へのこだわりでもあります。ビジネスに近づくには、ビジネスを理解する必要があります。ビジネスを理解するだけでなく、ビジネスのほとんどを理解する必要があります。この種の追求により、レベルを上げて最も本質的な質問、つまりどのような問題を解決したいのかに戻ることができます。どうすればより良く解決できるでしょうか？
DDD を学ぶのが難しい
不知道大家是否有这样困惑：DDD的学习过程好像是”大海捞针“的过程。即使能够捞到点东西，使用起来，还是会有种“东施效颦”的感觉，并不是很自然。为什么学习DDD那么困难呢？
▐ 感受：不得其门
论语中的下面这个场景，和我们的困惑是比较相似的：
叔孙武叔语大夫于朝曰：“子贡贤于仲尼。” 子服景伯以告子贡，子贡曰：“譬之宫墙，赐之墙也及肩，窥见室家之好；夫子之墙数仞，不得其门而入，不见宗庙之美、百官之富。得其门者或寡矣，夫子之云不亦宜乎！”
正如要感受到孔子达到的境界，自己的学问也需要有一定的积累。我们要感受到DDD的力量，自己本身就要成长到一定程度（如：经历了一些成功或者失败的设计，有自己的经验或者教训），才能形成共鸣和认同。
工作中，的确很少看到DDD的最佳实践。在复杂的业务面前，谁也没有勇气说，哪个软件结构是理想的设计：
因为这不是一个确定性的问题分解，你的设计会被放在显微镜下研究，总能找到各种反例。
而且，我们深知，最佳的实践，一定是做得足够的“软”，对扩展留有设计，能够随着业务发展而迭代，不是一个静态的结果。
因此，打开学习的大门不是几个案例就能一蹴而就的，需要结合我们自己的工作，慢慢累积、体会。
▐ 困难：模式发散
我们有一种困惑，到底怎么样算是DDD：
实践的个例，难以信服：当我们看到”DDD实践“的时候，可能会发问：这也算DDD？不就是一个正常的服务端框架与方案，也无法涵盖其它的场景或者部门系统。
抽象的理论，觉得空洞：当我们看到”抽象的DDD定义与策略“的时候，可能会发问：这也算DDD？不就是一些软件设计的共识，然后强加了一些名词定义，有些策略与我们手上的系统也并不匹配。
无论往抽象看，还是往具体实现看，都很难找到令人信服的理论与实践（能够有确定性的落地能力）。因为这不像23个设计模式那样，可以通过N个模版就能涵盖大多数的模式。
为什么不能产生特定的模式呢？可以结合下图进一步来看：
抽象理论：如同抽象的接口一样，"DDD理解"最上面的学习主要是理论定义，比如：聚合根、值对象、资源库、核心域、支撑域等各种定义，这些是易于理解掌握的。
通用实践：如同相对具体的抽象类一样，"DDD理解"中间层次是一些通用原则和技巧，比如：上下文的映射策略、架构的选择等。这些因素是确定的，但需要自主进行取舍与选择，并且需要与时俱进，增量的部分需要你自己学习补充。
具体实践：如同具体的类实例一样，"DDD理解"中下面层次是一系列的具体实践，结合各自的业务场景，进行了不同因素的设计、取舍与补充。因为涉及的选项较多，造成最终的选择结果往往是发散的，令人感觉“千人千面”。
两者不同的地方是：
“代码抽象层次”中层次关系是比较明确的，且有约束。
“领域驱动理解层次”中无法提供明确的约束，都是多个策略的取舍、一些关键的建议。
因此，由于问题的抽象层次较高，各种策略的不确定性较高，很难在DDD中产生像”23个设计模式“那样精炼的模式。一定要有的话，也是一系列的模式，比较发散。
DDD理解层次的类比
因此，我们渐渐明白：DDD面向的是软件的“软”，涵盖方方面面。DDD的深入理解，需要“千锤百炼”后，才能明白那些深入简出的建议，才能体会那句“师傅领进门，修行靠个人”的真言，才能感受到“众里寻他千百度，那人却在灯火阑珊处”的美妙瞬间。
基于设计原则看DDD
虽然DDD本身的实践可能千人千面，但是一些核心主题的思考应该是聚焦的，这些高频主题的理解，能让我们更好地进行设计，讨论的性价比也是较高的。接下来，会基于“6大设计原则”（solid 原则）为引子，去看看DDD中的一些关键理解。
▐ 单一职责原则：领域划分
单一职责是说：一个类应该只有一个发生变化的原因。职责的单一，可以更好地内聚，减少耦合，方便演化。
DDD里面的领域划分可以类比思考。对领域的划分，无论是按领域实体，还是按照功能模块，还是按照服务等划分，其实都想尽量保证领域的正交，能够独立演化和发展。
Single Responsibility Principle：单一职责原则
领域怎么切分比较合适？刚进入业务平台的时候，了解到领域切分是按“一个或多个实体对象”的边界来切分。这的确比较合理，因为领域的核心职责就是对领域实体进行管理。但这是果，还是因？在切分的时候，是因为我们有了对领域的判断，所以某些实体被分在一起比较合适；还是因为某些实体有明显边界，所以可以形成一个领域？就比如下面的图：
可以整体作为1个部分。
可以按竖着的正、负切分2个部分：上面1个（红），下面2个（黄、绿）。
可以按横轴的正、负切分2个部分：左边1个（黄），右边2个（红、绿）。
可以切分成3个部分（红、黄、绿）。
聚类的例子
这的确引入深思。切分比较容易的时候，往往是因为已经有了行业的标准（如：电商系统有订单、支付、物流、库存等领域是比较合理的）。那行业的标准来自哪里？是来自于演化：
开始的时候，可能只是一个大交易，比如：支付开始的时候只是买卖双方自己协议，也不需要建模。
后面支付发展了，也就独立出来一个域。原来不需要专人维护，后面会渐渐拉出一个团队来承接相关研发。
所以，领域的演化和划分，很类似“启发式算法”（一个基于直观或经验构造的算法，在可接受的花费下给出待解决组合优化问题每一个实例的一个可行解）：
初始化：按照的经验初步的划分，也可以是行业标准（没有行业标准的时候，就只能靠经验了）。
花费评价：生产、交付过程的人力成本度量，关注理解成本、开发效率、系统稳定性、运维成本等因素。
更优解：在业务发展过程中，计算花费评价，分析影响评价的“好因素”、“坏因素”，进行进一步调整。
往往到最后，我们会发现：
调整的内容：其实是匹配生产关系。
调整的原则：追求职责的内聚，精细化分工。
不断调整的原因：业务在发展，内聚的标准需也要与时俱进。
此外，从关联的角度看，往往我们看组织架构，就能看到领域的边界，核心原因还是组织架构也是要适应生产关系，follow更优解的结构，是相辅相成的，也就能互相窥探。
▐ 开闭原则：实体行为
开闭原则是说：软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是对于修改是封闭的。也就是说，对扩展区块是要有设计的，扩展的部分不应该影响稳定逻辑。
在DDD中，实体的行为，在保证对外封闭的情况下，也是需要考虑扩展能力的。
Open Closed Principle：开闭原则
在刚开始学习DDD的时候，我们可能会强行把一些逻辑放到实体中，进行控制和收敛。但后面随着业务的变化，会发现在实体中承担行为逻辑很难受：
影响较大：很难有勇气去频繁地修改一个核心类。
过于集中：随着方法和逻辑的增多，实体越来越臃肿。
场景较多：很多逻辑并不是正交的，不是 if 这样 else 那样的，充满着交集与叠加。
抛弃 POJO 的get、set，走向实体的丰富行为，让我们编写代码更加困难了么？其实，我们的烦恼来自于，太关注实体行为的收口，忽略了扩展的设计：
原来 get set 写法很舒服的本质在于，很多的扩展被放在了业务脚本中，业务脚本虽然千疮百孔，但是是在应用层，远离核心逻辑。底层模型、通用组件等基础逻辑还是比较干净的。
应用DDD的时候，把一些行为下沉到领域层之后，也是要考虑扩展的。如果只关注收口，不关注扩展，那的确是“画地为牢”、“捡了芝麻，丢了西瓜”。
但是，要突破这一个困境，能够在实体行为中设计扩展，其实要有这样的认同：要往上看一个层次，就是实体行为的表达，不一定只有一个类完成，可以通过策略模式等方式的路由，由一个模块中的一些类进行完成，只要对外有封装和管控其实就可以了。
突破一个类的限制，走向更多的类的协作设计，也是我们进阶的方向。
▐ 里氏替换原则：资源库
里氏代换原则是说：任何基类可以出现的地方，子类一定可以出现。讲究的是合理的抽象和复用。引人深思的一个例子是：正方形是特殊的长方形，正方形如果作为长方形的子类，那么当设置长度的时候就会出现冲突，长方形的长和宽可以独立设置，正方形的长和宽是有约束的，使用继承的关系就比较别扭。
在DDD中，关于可替代性，想聊一聊资源库。
Liskov Substitution Principle：里氏替换原则
资源库的替代性需求
在原来的分层的架构中，数据库等存储能力作为一种底层基础设施，是被视为稳定的下层服务的。但在实际的交付过程中，往往要遇到不同场景：
本地部署：线下零售交易为了服务稳定性，期望可以具备本地保存数据的能力。
云上产品：售卖给外部企业的交易产品，成本的要求也不尽相同，期望在云上采购不同的存储服务。
这些场景，让大家逐渐深信：当面向更广阔的市场，基础设施也是充满着不确定性，需要具备可替换的能力。
存储实现间的复用策略
在具体实现的过程中，并不是每个领域都会独立部署，有些领域因为组织、性能的因素会一起部署。往往这些领域的代码也是在一个项目模块中的。出于横向效率的考虑，会设计统一的存储框架。
不同设施的存储能力不同，但整个存储流程又是类似的（协议转换，存储语句生成、执行与事务，返回结果），这样在不同存储能力的过程复用方式上需要进行取舍（数据库、Tair等是分开抽象还是统一抽象）：
如果“大一统”为主，那么针对关系型存储、KV存储等不同存储进行抽象的时候，就会和“长方形与正方形的问题”一样犹豫：
收益：如果你长期维护，了解里面的特殊性，的确是可以省略一些主体代码，提高开发效率。
代价：但大多数人要做扩展的时候，会感到很多不解，有很多本不需要的适配，充满迷惑。
如果以组合为主，那么可以通过多套模版，更好地进行自主选择。这样分而治之，减少了大家的理解成本，也能独立演化，更能适合存储的能力特性。但是需要沉淀多套理解，往往也缺少人力支持。
我想，“基于不同的存储能力，设计不同的模版框架” 应该是首选。大一统的抽象，开始时，人力成本可能低一点，但因为抽象层次较高，在理解与维护上将是一个“人力成本黑洞”，随着时间的推移，会降低整体收益，长期看是得不偿失的。反之，不同的模版复用，最终可以获得更好的整体收益。
▐ 迪米特法则：领域协作
迪米特法则，又称最小知识原则，是说：一个软件实体应当尽可能少的与其他实体发生相互作用。应该和一些“关键类”进行沟通。
DDD里面，领域间的协作，也需要相关的规划和设计。如果对领域之间的相互调用不做管理，那么链路关系会膨胀到难以理解的地步。
Law of Demeter：迪米特法则
设计模式中，无论是中介者模式，还是外观模式，都希望通过集中管理，让多对多的复杂关系，简化为多对一、一对多这样易于理解的结构。类似的，在领域协作与对外交付的过程中，往往可以增加一个协调层，去串联各个域的交互。这样即可以降低各域的协作成本，也可以降低外部的理解成本，有更好的研发体验。
协调层该如何产生？好比上课：虽然老师可以教，但是老师不在时，可以指定学生代理上课。学生虽然可以干，但教学技巧并不熟练，自己本身还有学习的职责，角色也很尴尬。下面将讨论一下协调层和域的角色关系。
域能否成为协调层
比较值得讨论的是交易里面“交易域”、“订单域”这样的概念：
“交易域”看上去是负责整个交易过程，可以协调各个域，逻辑上比较合适成为协调者，但是主要还是在管理订单，其它赋予的协调能力，这部分并没有领域实体。
“订单域”看上去只是负责订单本身的服务，不太关心其他域，但是因为订单合约上有着所有合约信息（无论是直接还是间接持有），这意味着，“订单域”本身就有协调的潜力，只是职责看上去不够单一而已。
没有实体，为什么会有“交易域”一说，本人是这么理解的：在交易流程等可以强管控的情况下，把交易的API服务当做域服务（如：下单），“交易域”在逻辑上是有边界、可以成立的。但本质还是在管理订单，靠订单域成为了域，同时想沉淀协调能力。
調整層はドメインになれるか
したがって、注文モデルの管理がトランザクション管理に与えられていない場合、これは私が常に考えている質問です。独自のデータベース エンティティがなく、メモリ モデルのみが存在し、純粋に下流ビジネスの理解に依存している場合は、アクティビティとデータフロー、それはドメインになれるでしょうか？
答えはおそらくノーです。
論理的には、個人は純粋に領域として理解することで認識しますが、結局のところ、知識自体も資産です。
しかし実際には、通信事業者がなければステータス記録やデータサービスなど多くのことができず、支援することしかできず、核となる競争力がなければ生き残ることは困難です。
コーディネーターの役割は、比較的認知された「ドメイン」になるために、データ モデルを単独で保持するか、基本ドメインのいくつかのデータ モデルの助けを借りて、管理権限を享受する必要があります。
調整レイヤーの名前
ドメインがコーディネーターの役割を引き受けたいのか、コーディネーターがドメインに発展したいのか、単一責任の論理には当てはまりませんが、そのような「兼業」は頻繁に発生し、核となるのは開発者の重複です役割。
調整層はドメインから選択するのに適しておらず、ドメインにも適さないので、各ドメインの事業活動と能力の間の調整部分を何と呼ぶべきでしょうか。現状では「商力」や「ソリューション」といった言葉の方が適切だろう。
▐インターフェース 分離原則: ビジネス活動
インターフェイス分離の原則では、クライアントは必要のないインターフェイスに依存すべきではありません。クラスの別のクラスへの依存関係は、最小のインターフェイスに基づく必要があります。
DDD でのドメイン構築を学ぶことに加えて、アプリケーション層がビジネス リクエストをより適切に処理する方法にも注意を払い、ビジネス ロジックのセグメント化の基礎を学ぶ必要があります。」
インターフェイス分離の原則: インターフェイス分離の原則
ルールがないと立ち回るのが難しい
以前、事業部門で業務を行っていたときは、業務活動やプロセスといった概念がなく、業務ニーズに基づいて業務スクリプトを書くことが多く、経験値がコードの洗練さに影響を与えていました。しかし、経験は別として、アプリケーション層のさまざまなビジネス ロジックを実行するためのより優れた構造フレームワークや原則を誰もが持っていないため、疑問もいっぱいです。
外部サービスインターフェースはどのようにセグメント化すべきでしょうか?
同様のサービス間でプロセスを共有できますか?
業務執行プロセスをさらに構造化し、細分化するにはどうすればよいでしょうか?
……
標準化が行われない結果として、誰もが独自の意見を持つことがよくあります。誰もが一連の構造を確立したいと考えていますが、誰も他の構造に同意しません。それぞれが独自のコード領域を持っています。
安定したプラットフォームのフレームワーク
このプラットフォームは長い間考え、管理されており、比較的安定したコンセンサスがあるため、現在機能しています。ビジネスの入り口とビジネスの入り口の間、ビジネスの入り口と安定したロジックの間の全体的な設計は、シナリオベースのロジックを実行するためのスペースと拡張機能を確保しており、その構造は比較的明確です。
事業活動に応じて入口が細分化され、事業活動に応じてサービス入口が拡張され、コアはユースケースを理解し、どの役割が何をする必要があるのかに注目します。
プロセスに依存しない取り組みとオーケストレーション: ビジネス アクティビティは、多重化レイヤー (ドメイン サービス、外部サービス、ビジネス拡張など) に到達する前に、独立したままであり、オーケストレーションされます。
プロセス ファイルを使用して実行プロセスを調整します。実行プロセスを実行ノードにセグメント化します。ノードのセグメント化は、「ファンクション ポイント」、「関与するドメイン」、「関与するエンティティ」などに基づいて行うことができます。ノード間の共通機能は、基本機能に組み込まれます。
……
繰り返しのレビューで合意形成
分割して征服し、全員の焦点を絞り、分割して協力することを改善します。これは非常に理解しやすく、受け入れやすいものです。ただし、適切な分割を確保するには、統一された合意と原則が必要です。
多くの場合、合意形成は、先に合意をしてから分割するのではなく、最初のコミュニケーションを経て分割を試み、レビューで合意に達し、紆余曲折の中で前進することが多いです。全員の意見や対立が比較的大きい場合、合意に達するプロセスは比較的遅くなります。幸いなことに、この種のセグメント化は頻繁に発生するものではなく、大きな需要や大規模なリファクタリングが発生する場合にも発生します。現時点では、確保されている研究時間と開発リソースも十分です。
依存関係逆転の原理: ヘキサゴナル アーキテクチャ
依存関係逆転の原則は、プログラムは具体的な実装ではなく、抽象インターフェイスに依存する必要があるということです。
DDD で言及されているヘキサゴナル アーキテクチャは、ドメイン構築をアーキテクチャの中核目標として、抽象コアのステータスをさらに強化します。
依存関係逆転の原理: 依存関係逆転の原理
フィールドを中心とすることは、実際には比較的重要な変更です。
以前は、レイヤード アーキテクチャが主な焦点でした。レイヤーに注目し、機能をできる限り低くし、より多くのツールを再利用し、共通コンポーネントを蓄積するように努めました。
次に、その分野に焦点を当てます。抽象化のレベルに注目し、理解をその分野の核心に統合し、より多くの「理解」再利用を実行して、ビジネス知識を蓄積します。
このような変化により、私たちは意識的に「ドメイン理解」を核として、業界競争力を形成し、「知識」を資産として販売することが可能になります。
ドメイン カーネルの抽象化を確実にするためには、ドメイン カーネルの境界を定義する必要があります。インターフェイスには次の 2 種類があります。
アップストリームに提供される機能: インターフェイス宣言を通じて、引き受けることができる責任を説明し、ドメイン内でサポートを実装します。
ダウンストリーム機能への依存: 外部サービス、ビジネス拡張機能のカスタマイズ、およびストレージ サービスはすべてダウンストリーム サービスと見なすことができ、サービスの依存関係はインターフェイスを通じて宣言されます。
ドメイン コアと外部の間のインターフェイスが分離されていることがわかります。より基本的なサービスについては、アプリケーション層に属するビジネス入口と同じ外部ポートとみなされます。たとえば、ストレージ サービスは次のとおりです。
データ フレーム + DO、変換を理解する必要がなく、変換は上流で完了し、DO は上流でもコア モデルとして使用されます。アップストリームは循環のコアオブジェクトとして DO を完全に使用します。
これで、これは「ビジネス コンポーネント」として理解できるようになります。ドメインのストレージ インターフェイスを実装し、プロトコル変換を実行し、ドメイン オブジェクトをデータ ストレージ オブジェクト DO に変換する必要があります。DO はドメインによって直接理解されませんが、カーネルはドメイン オブジェクトに変換してから外部に公開する必要があり、カーネルによってパフォーマンスが定義されます。
この種のアーキテクチャは、ドメイン理解の抽象的な中心的な位置を確立し、研究開発の学生がビジネス上の問題について考えることにもっと注意を払うことを可能にし、単なる「ビジネス上の問題に近い」より多くの「血肉」のソフトウェアを構築します。ソフトウェアの複雑さに対処するプロセスでは、顧客の価値に近づくという方向性がより認識されています。
要約する
DDD の追求は、さまざまなビジネス上の問題をエレガントに解決したいという願望から来ており、一連のフレームワークが問題を分解し、安定した効率的な生産効率を得るのに役立つことを期待しています。
しかしそれは「永久機関」の探求と同じで、明確な答えを出すことが難しい過程です。ソフトウェアの複雑さを解決するソリューションは、関連するシナリオと組み合わせて継続的に進化する必要があり、単に DDD を追求するだけでは「特効薬」は得られません。
しかし、「永久機関」の研究と同じように、エネルギーの変換プロセスに焦点を当てることができ、より効率的なエネルギー機械の作成につながる可能性があります。DDD の研究と追求により、ビジネスの深い理解にもっと注意を払うことができ、拡張しやすいコード実装を作成できるようになります。
「事業の継続的な発展」と「ソフトウェアの複雑さ」があるからこそ、プログラミングは課題に満ち、フレームワークの研究に熱中できるのだと思いますが、これは素晴らしいことではないでしょうか。
チーム紹介
私たちはビッグタオバオテクノロジー取引プラットフォームチームです。このチームは主にトランザクション リンクの配信に従事しており、配信作業、水平製品機能 (プリセールス、電子バウチャーなど) の抽象化と構築では、ビジネス アーキテクチャ、DDD およびその他の理論に焦点を当てています。アクセスと抽象的なエンパワーメント。
¤ 拡張読書 ¤